Re: pg_autovacuum: short, wide tables - Mailing list pgsql-bugs

From Matthew T. O'Connor
Subject Re: pg_autovacuum: short, wide tables
Date
Msg-id 42CEB611.7020107@zeut.net
Whole thread Raw
In response to Re: pg_autovacuum: short, wide tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_autovacuum: short, wide tables
List pgsql-bugs
Tom Lane wrote:

>"Matthew T. O'Connor" <matthew@zeut.net> writes:
>
>
>>Shouldn't the update to the toast table just be considered an update to
>>table t1?  The fact that there is an underlying  toast table is an
>>implementation detail that I don't think should show up in the stats system.
>>
>>
>
>At the level of the stats system, though, you are interested in
>"implementation details".  The fact that there is such a concept as an
>index is an implementation detail according to the SQL standard --- but
>if we hid that we wouldn't be able to show things that people want to
>know.
>
>In particular, I think people would like to be able to use the stats
>views to see how much toast-related I/O is going on, and not have that
>smushed together with main-table I/O.
>

Fair enough, but how are you planning to display the data, if the stat
system just reports that there was an update to a corresponding toast
table, that still isn't going to tell us how many pages that updated
effected, and then we are back to the all updates are not created equal
problem.  Currently autovac doesn't look at the block level stats, maybe
it should for this reason.

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_autovacuum: short, wide tables
Next
From: Tom Lane
Date:
Subject: Re: pg_autovacuum: short, wide tables