On Friday 14. of May 2010 20:02:02 Tom Lane wrote:
> Rumko writes:
> > On Friday 14. of May 2010 19:29:44 Tom Lane wrote:
> >> Hmm, do both of the toast tables with bloat problems have
> >> "{autovacuum_enabled=false}" ?
> >
> > Yeah, but also many others that don't have the problem.
>
> Hmm, well
Rumko writes:
> On Friday 14. of May 2010 19:29:44 Tom Lane wrote:
>> Hmm, do both of the toast tables with bloat problems have
>> "{autovacuum_enabled=false}" ?
> Yeah, but also many others that don't have the problem.
Hmm, well I can reproduce the problem after doing
alter table foo set (toast
On Friday 14. of May 2010 19:29:44 Tom Lane wrote:
> Rumko writes:
> > On Thursday 13. of May 2010 21:43:37 Tom Lane wrote:
> >> Do *any* of the rows in pg_class have non-null reloptions?
> >
> > First of all, really sorry.
> > "select reloptions from pg_class where relname = 'pg_toast_1066371';"
Rumko writes:
> On Thursday 13. of May 2010 21:43:37 Tom Lane wrote:
>> Do *any* of the rows in pg_class have non-null reloptions?
> First of all, really sorry.
> "select reloptions from pg_class where relname = 'pg_toast_1066371';"
> Returns "{autovacuum_enabled=false}" (a remnant of some testin
On Thursday 13. of May 2010 21:43:37 Tom Lane wrote:
> Rumko writes:
> > As far as I'm concerned, the TOAST table itself does not bother me even
> > if I have a few bytes per row there, only the part where VACUUM claims no
> > free space even though pages are more empty than not.
>
> Yeah, that's
Rumko writes:
> On Thursday 13. of May 2010 17:24:47 Tom Lane wrote:
>> You might want to think about collapsing all those standalone bigint
>> columns into an array.
> The current design is not final yet, but for now it has proven (with the
> exception of the 2 tables that have giant toast tabl
On Thursday 13. of May 2010 17:24:47 Tom Lane wrote:
> Rumko writes:
> > Tom Lane wrote:
> >> There's something extremely wacko about that vacuum output.
> >
> > Regarding storage paramaters, you mean ALTER TABLE x SET STORAGE...? Then
> > no.
>
> No, I was wondering about ALTER TABLE ... SET (fil
Rumko writes:
> Tom Lane wrote:
>> There's something extremely wacko about that vacuum output.
> Regarding storage paramaters, you mean ALTER TABLE x SET STORAGE...? Then no.
No, I was wondering about ALTER TABLE ... SET (fillfactor = n).
It would be worth checking to see if you get a nonnull re
Tom Lane wrote:
>
> There's something extremely wacko about that vacuum output. A toast
> table should have few, if any, rows that short. And it's impossible
> to believe there's no free space at all in the table, especially since
> 122*3259181 bytes is still quite a lot less than 3259181 pages
Rumko writes:
> INFO: vacuuming "pg_toast.pg_toast_1066371"
> INFO: "pg_toast_1066371": found 0 removable, 3259181 nonremovable row
> versions
> in 3259181 pages
> DETAIL: 0 dead row versions cannot be removed yet.
> Nonremovable row versions range from 57 to 122 bytes long.
> There were 0 unu
10 matches
Mail list logo
