Re: [PATCH] reloptions - RELOPT_KIND_ALL

I attached patch which add capability to have single record for all
realation kind in the reloption list. It is usefull in situation when
all parameters are same for all relation kinds.

Zdenek

Zdenek Kotala escreveu:
> I attached patch which add capability to have single record for all
> realation kind in the reloption list. It is usefull in situation when
> all parameters are same for all relation kinds.
>
Doesn't work. One of the reasons to separate relation kinds was that different
kinds have different min/max values (see fillfactor for an example).

--
Euler Taveira de Oliveira
http://www.timbira.com/

Zdenek Kotala wrote:
> I attached patch which add capability to have single record for all
> realation kind in the reloption list. It is usefull in situation when
> all parameters are same for all relation kinds.

Do you have an example use case for this?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
> Zdenek Kotala wrote:
> > I attached patch which add capability to have single record for all
> > realation kind in the reloption list. It is usefull in situation when
> > all parameters are same for all relation kinds.
>
> Do you have an example use case for this?

I use it in my space reservation patch. I going to send it soon. The
default value is zero in all relkind and max value as well. It seems to
me waste a space to copy and paste same lines several times.

Zdenek

Zdenek Kotala wrote:
>
> Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
> > Zdenek Kotala wrote:
> > > I attached patch which add capability to have single record for all
> > > realation kind in the reloption list. It is usefull in situation when
> > > all parameters are same for all relation kinds.
> >
> > Do you have an example use case for this?
>
> I use it in my space reservation patch. I going to send it soon. The
> default value is zero in all relkind and max value as well. It seems to
> me waste a space to copy and paste same lines several times.

Hmm, but is it really applicable to all relkinds? Is it applicable to
GIN indexes for example? Keep in mind that GIN does not even have
fillfactor. How are you going to make space reservation work for GIN?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera píše v pá 23. 01. 2009 v 11:14 -0300:
> Zdenek Kotala wrote:
> >
> > Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
> > > Zdenek Kotala wrote:
> > > > I attached patch which add capability to have single record for all
> > > > realation kind in the reloption list. It is usefull in situation when
> > > > all parameters are same for all relation kinds.
> > >
> > > Do you have an example use case for this?
> >
> > I use it in my space reservation patch. I going to send it soon. The
> > default value is zero in all relkind and max value as well. It seems to
> > me waste a space to copy and paste same lines several times.
>
> Hmm, but is it really applicable to all relkinds? Is it applicable to
> GIN indexes for example? Keep in mind that GIN does not even have
> fillfactor. How are you going to make space reservation work for GIN?

Yes it is. I need two new reloptions - rs_perpage and rs_pertuple. I
don't use fillfactor. I modified PageGetFreeSpace function to return
correct value.

These two options are applicable on all relkind (including toast*) which
use standard page layout - currently all AM.

Zdenek

* I know that toast is not supported yet.

Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> Alvaro Herrera pe v p 23. 01. 2009 v 11:04 -0300:
>> Do you have an example use case for this?

> I use it in my space reservation patch. I going to send it soon.

Haven't we been over that ground already? A user-settable reloption
is not a reasonable solution to a space-reservation problem. The
potential for errors of commission and omission is too great.

regards, tom lane

Tom Lane píše v pá 23. 01. 2009 v 10:19 -0500:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> > Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
> >> Do you have an example use case for this?
>
> > I use it in my space reservation patch. I going to send it soon.
>
> Haven't we been over that ground already?

Maybe I overlooked something, but IIRC that we discussed only TOAST
chunks which is different problem.

> A user-settable reloption
> is not a reasonable solution to a space-reservation problem. The
> potential for errors of commission and omission is too great.

Hmm, yeah it could be dangerous, but on other side new columns in
pg_class doesn't protect superuser to set incorrect values. I guess that
put constrains on pg_class are not good idea and wrong values could
cause server crash (when reservedspace will be greater then BLCKSZ).
What about reloptions which can be set only by superuser? Or any other
idea?

Zdenek

Zdenek Kotala wrote:
> Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
>> Zdenek Kotala wrote:
>>> I attached patch which add capability to have single record for all
>>> realation kind in the reloption list. It is usefull in situation when
>>> all parameters are same for all relation kinds.
>> Do you have an example use case for this?
>
> I use it in my space reservation patch. I going to send it soon. The
> default value is zero in all relkind and max value as well. It seems to
> me waste a space to copy and paste same lines several times.

Aside from the other issues mentioned, ISTM the amount of space
reservation wanted depends on the exact changes across releases that
make that space reservation necessary in the first place. And depending
on what those changes are, the space reservation requirements could be
wildly different for each access and storage method.