Re: Inaccuracy in VACUUM's tuple count estimates - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Inaccuracy in VACUUM's tuple count estimates
Date
Msg-id 1402326052.35096.YahooMailNeo@web122303.mail.ne1.yahoo.com
Whole thread Raw
In response to Re: Inaccuracy in VACUUM's tuple count estimates  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Inaccuracy in VACUUM's tuple count estimates  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> wrote:

> Well, I think reverting surely wouldn't be the right cure. It
> fixes a somewhat nasty bug. I'd certainly be prepared to add the
> two lines necessary to make it return DELETE_IN_PROGRESS after
> trying to understand Kevin's email about predicate.c and going
> through the other callers another time.

I'm not actually sure yet whether the current state of affairs
causes a problem for the serializable transaction isolation level
implementation.  The most important thing to me is that whatever is
implemented is accurately documented in code comments so I can make
any necessary adjustments to code in predicate.c -- or possibly
determine that I *do* need some change to HTSV.  Right now the HTSV
embedded code comments suggest that the enum names and comments
don't accurately describe the conditions under which they are
returned, but I can't find anything else which does, short of
reverse-engineering that from some fairly complex code.

Perhaps it would be good if you could provide a concise description
of the conditions under which value could currently be returned on
this (or the related) thread before we talk about what changes
might be needed?  Maybe this is clear to others involved in the
discussion, but I am not confident that I fully understand what
gets returned under what conditions.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Linos
Date:
Subject: Re: performance regression in 9.2/9.3
Next
From: Robert Haas
Date:
Subject: Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller