Takahiro Itagaki wrote:
> Could you explain why default_only entries idea is
> better than adjusting those fields in the toast-specific codes?
> It's my understanding that reloption-framework is just a tool to fill
> reloption parameters, and it's not responsible for unused fields.
Here is my p
Tom Lane wrote:
> Alvaro Herrera writes:
> > Do we really need default_only entries in user-defined reloptions?
I think we don't, but I also think we don't need it at all even in the
core because it just set a few variables to the default values with
complex code flow. Could you explain why de
Alvaro Herrera writes:
> Excerpts from Takahiro Itagaki's message of mié may 26 03:32:56 -0400 2010:
>> The new "default_only" field can be initialized only from the internal codes
>> and is not exported to user definded reloptions. We could add an additional
>> argument to add_xxx_reloption() fu
Excerpts from Takahiro Itagaki's message of mié may 26 03:32:56 -0400 2010:
>
> Alvaro Herrera wrote:
>
> > Excerpts from Tom Lane's message of vie may 14 15:03:57 -0400 2010:
> >
> > > Maybe a better solution is to have some kind of notion of a default-only
> > > entry, which is sufficient to
This is still an open item for 9.0, and we should also backport it to 8.4.
Which do we take on? Or is there better idea?
Alvaro's idea:
> > > Maybe a better solution is to have some kind of notion of a default-only
> > > entry, which is sufficient to insert the default into the struct but
> > > is
Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of vie may 14 15:03:57 -0400 2010:
>
> > Maybe a better solution is to have some kind of notion of a default-only
> > entry, which is sufficient to insert the default into the struct but
> > isn't accepted as a user-settable item.
>
> Th
Excerpts from Tom Lane's message of vie may 14 15:03:57 -0400 2010:
> Maybe a better solution is to have some kind of notion of a default-only
> entry, which is sufficient to insert the default into the struct but
> isn't accepted as a user-settable item.
This patch (for 8.4, but applies fuzzily
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of vie may 14 14:19:30 -0400 2010:
>> What seems more rational is to provide toast.fillfactor but give it
>> min/max/default = 100.
> Adding an entry to intRelOpts should be enough to fix this bug, correct?
I think so, but haven't tested.
Excerpts from Tom Lane's message of vie may 14 14:19:30 -0400 2010:
> The problem is that if any reloption is set for the toast table,
> we build a StdRdOptions struct in which fillfactor is zero, and
> then all the code that actually uses fillfactor honors that.
> And the reason fillfactor gets l
I've been able to reproduce the problem described here:
http://archives.postgresql.org/pgsql-bugs/2010-05/msg00100.php
Do this:
create table foo(f1 text);
alter table foo set (toast.autovacuum_enabled = false);
insert into foo values(repeat('xyzzy',10));
vacuum verbose foo;
Notice that the va
10 matches
Mail list logo
