Thread: [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
Attachment
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.Kotala@Sun.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? 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.Kotala@Sun.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.