Prev: JSON manipulation functions
Next: Generalized Inverted Generalized Search Tree
From: Tom Lane on 14 May 2010 14:19
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',100000));
vacuum verbose foo;

Notice that the vacuum output shows there's only one toast tuple per
toast table page.

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 left as zero is that there is no
entry for it in the tables for toast-table reloptions. Clearly,
this wasn't thought through carefully enough.

I'm inclined to think that we should remove the notion of there
being separate sets of rdoptions for heaps and toast tables ---
any case in which someone tries to omit a StdRdOption for toast
tables is going to fail the same way, unless we are fortunate
enough that zero is a desirable default. What seems more rational
is to provide toast.fillfactor but give it min/max/default = 100.

Thoughts?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: JSON manipulation functions
Next: Generalized Inverted Generalized Search Tree