From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong |
Date: | 2008-04-02 23:04:09 |
Message-ID: | 17953.1207177449@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
I wrote:
> ... What I propose therefore
> is combining this patch with my older one so that ANALYZE counts
> according to the following rules:
> REDIRECT line pointer: ignore
> DEAD line pointer: count as dead
> HEAPTUPLE_LIVE tuple: count as live, include in statistics pool
> HEAPTUPLE_DEAD: count as dead
> HEAPTUPLE_RECENTLY_DEAD: count as dead
> HEAPTUPLE_INSERT_IN_PROGRESS: ignore
> HEAPTUPLE_DELETE_IN_PROGRESS: count as live
While working on this I realized that there's a special case ANALYZE has
to face that is not faced by VACUUM: it might see tuples inserted or
deleted by its own transaction. For example consider
begin;
... load lots of data into mytable ...
analyze mytable;
... issue complex queries against mytable ...
commit;
This is not an uncommon scenario, particularly with respect to temporary
tables. ANALYZE's historical behavior of sampling everything that's
good according to SnapshotNow does the right thing here, but ignoring
INSERT_IN_PROGRESS tuples would not.
The right way seems to be to treat our own insertions as live during
ANALYZE, but then subtract off our own pending insertions from the
live-tuples count sent to the stats collector. pgstat_report_analyze()
can handle the latter part by groveling through the backend's pending
statistics data.
Comments?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Mayer | 2008-04-02 23:41:16 | modules |
Previous Message | Bruce Momjian | 2008-04-02 23:03:09 | Re: [GENERAL] SHA1 on postgres 8.3 |
From | Date | Subject | |
---|---|---|---|
Next Message | Decibel! | 2008-04-02 23:05:39 | Re: writing a MIN(RECORD) aggregate |
Previous Message | Bruce Momjian | 2008-04-02 23:03:09 | Re: [GENERAL] SHA1 on postgres 8.3 |