On 7/8/2005 12:57 PM, Tom Lane wrote:
Mark Reid <[EMAIL PROTECTED]> writes:
I think the issue is that a single update to the main table causes a
whole bunch of updates to the toast table. So in my case (with the
vacuum output attached previously), a thousand updates to the main table
entails
I'm not proposing it for 8.1 though ...
Well, why not? Arguably Mark's problem is a bug, and it's not too late
to address bugs.
FWIW, I'd be satisfied with a warning in the autovacuum docs about this
corner case.
I'm not sure about the idea of not vacuuming the toas
Matthew T. O'Connor wrote:
Tom Lane wrote:
I think Mark is probably on to something. The activity in the toast
table will show as deletes *in the toast table* ... and that activity
fails to show at all in the pg_stat_activity view, because it shows
only plain relations! So unless autovacuum
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Note that it doesn't matter that it doesn't show up in the pg_stat
views, because we don't use those; rather we access the hash tables
directly.
Ah, but this is only true in the integrated version no? The contrib
version sure
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Another issue altogether is the stat system. I don't know if it stores
> info about toast tables.
Yes, it does --- you can pull out the info, even, if you use the stats
access functions directly. It's just that the views filter on relkind =
'r'.
> No
On Fri, Jul 08, 2005 at 02:35:14PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Fri, Jul 08, 2005 at 01:29:03PM -0400, Tom Lane wrote:
> >> The main bit of additional logic that might be needed is an awareness
> >> that firing a VACUUM on a main table will implicitly f
Tom Lane wrote:
I'm having some second thoughts about allowing VACUUM on a toast table
independently of its parent table --- it's a bit scary to be messing
with the toast table when we have no lock at all on the parent. It
might work OK, but I'm not sure I want to take the risk. If we simply
e
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Fri, Jul 08, 2005 at 01:29:03PM -0400, Tom Lane wrote:
>> The main bit of additional logic that might be needed is an awareness
>> that firing a VACUUM on a main table will implicitly fire one on its
>> toast table, and so you'd not want to go and iss
On Fri, Jul 08, 2005 at 01:29:03PM -0400, Tom Lane wrote:
> "Matthew T. O'Connor" writes:
> > Tom Lane wrote:
> >> 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
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Hmm. With integrated autovacuum, we could set something up to issue
vacuums separately to TOAST tables and the main table. It'd probably be
a tad easier if the toast stats are separate from the main table; and an
autovac of the main table not necessar
"Matthew T. O'Connor" writes:
> Tom Lane wrote:
>> 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,
Tom Lane wrote:
"Matthew T. O'Connor" 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 s
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> The first of these would be easiest but it seems quite likely to break
>>> applications (eg, if unmodified, autovacuum would probably try to issue
>>> vacuums against toast tables). And the last seems to be confusing.
>>> So I think
"Matthew T. O'Connor" 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, y
Mark Reid <[EMAIL PROTECTED]> writes:
> I think the issue is that a single update to the main table causes a
> whole bunch of updates to the toast table. So in my case (with the
> vacuum output attached previously), a thousand updates to the main table
> entails tens of thousands of updates to
> Tom Lane wrote:
> >The first of these would be easiest but it seems quite likely to break
> >applications (eg, if unmodified, autovacuum would probably try to issue
> >vacuums against toast tables). And the last seems to be confusing.
> >So I think I favor adding columns.
Hmm. With integrated
Tom Lane wrote:
I think Mark is probably on to something. The activity in the toast
table will show as deletes *in the toast table* ... and that activity
fails to show at all in the pg_stat_activity view, because it shows
only plain relations! So unless autovacuum is ignoring the stats views
a
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> mark reid wrote:
>> What I believe is happening is that the main table doesn't meet the
>> minimum activity level for pg_autovacuum based on size / update
>> frequency, but the toast table would, though it isn't specifically
>> checked by pg_au
mark reid wrote:
I've been using pg_autovacuum for a while, and for the most part it's
been great. There's one case in my system where it won't run on a
particular type of table, even though the table apparently needs it.
I have a table called "properties" that has key->value pairs. Usually
Hi,
I've been using pg_autovacuum for a while, and for the most part it's
been great. There's one case in my system where it won't run on a
particular type of table, even though the table apparently needs it.
I have a table called "properties" that has key->value pairs. Usually
there are o
20 matches
Mail list logo
