>>> On Wed, Nov 21, 2007 at 12:32 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Has this issue been a real problem? If so, probably we should consider
>> adjusting ANALYZE for 8.3 per your proposal.
>
> I'm not sure. Upth
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Should we attempt to adjust VACUUM's accounting as well, or leave it
>> for 8.4? For that matter, should adjusting ANALYZE be left for 8.4?
>> Thoughts?
> Has this issue been a real problem? If so, probably we should consider
> adju
Tom Lane wrote:
> I feel fairly comfortable with this analysis for ANALYZE, and the
> patch I posted yesterday can easily be adjusted to accommodate it.
> However, what of VACUUM? As that code stands, every non-removable
> tuple (including RECENTLY_DEAD ones) is counted as live, and the
> dead-tu
On Mon, 2007-11-19 at 13:33 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2007-11-19 at 10:38 -0500, Tom Lane wrote:
> >> The race conditions are a lot more subtle than that. The stats
> >> collector cannot know when it receives a tabstat message after VACUUM
> >> st
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2007-11-19 at 10:38 -0500, Tom Lane wrote:
>> The race conditions are a lot more subtle than that. The stats
>> collector cannot know when it receives a tabstat message after VACUUM
>> starts whether VACUUM has/will see the tuples involved, or whet
On Mon, 2007-11-19 at 10:38 -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> On further thought though, that's not the whole story, and in fact
> >> VACUUM itself isn't doing very well at accounting for in-doubt tuples.
>
> > How about this: let's have V
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> On further thought though, that's not the whole story, and in fact
>> VACUUM itself isn't doing very well at accounting for in-doubt tuples.
> How about this: let's have VACUUM send a message at the start of
> processing the table. p
Tom Lane wrote:
> On further thought though, that's not the whole story, and in fact
> VACUUM itself isn't doing very well at accounting for in-doubt tuples.
> The current implementation is that whatever live and dead tuple totals
> are arrived at by a VACUUM or ANALYZE are sent to the stats colle
On Sat, 2007-11-17 at 12:27 -0500, Tom Lane wrote:
> I feel fairly comfortable with this analysis for ANALYZE, and the
> patch I posted yesterday can easily be adjusted to accommodate it.
> However, what of VACUUM? As that code stands, every non-removable
> tuple (including RECENTLY_DEAD ones) is
Hi,
Please read the below is some skepticism. I am not an expert with
regard to statistics and vacuum internals. Hopefully it just keeps the
thinking caps moving.
Tom Lane wrote:
There was some discussion in pgsql-performance about the problem that
the live-and-dead-tuple counts that ANALY
There was some discussion in pgsql-performance about the problem that
the live-and-dead-tuple counts that ANALYZE reports to the stats
collector don't reflect insert-in-progress tuples properly:
http://archives.postgresql.org/pgsql-performance/2007-11/msg00225.php
I proposed a patch here:
http://ar
11 matches
Mail list logo
