From: | Mark Mielke <mark(at)mark(dot)mielke(dot)cc> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Conor Walsh <ctw(at)adverb(dot)ly>, jd(at)commandprompt(dot)com, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Does auto-analyze work on dirty writes? |
Date: | 2011-02-05 01:50:13 |
Message-ID: | 4D4CACD5.7060104@mark.mielke.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On 02/04/2011 10:41 AM, Tom Lane wrote:
> 1. Autovacuum fires when the stats collector's insert/update/delete
> counts have reached appropriate thresholds. Those counts are
> accumulated from messages sent by backends at transaction commit or
> rollback, so they take no account of what's been done by transactions
> still in progress.
>
> 2. Only live rows are included in the stats computed by ANALYZE.
> (IIRC it uses SnapshotNow to decide whether rows are live.)
>
> Although the stats collector does track an estimate of the number of
> dead rows for the benefit of autovacuum, this isn't used by planning.
> Table bloat is accounted for only in terms of growth of the physical
> size of the table in blocks.
Thanks, Tom.
Does this un-analyzed "bloat" not impact queries? I guess the worst case
here is if autovaccum is disabled for some reason and 99% of the table
is dead rows. If I understand the above correctly, I think analyze might
generate a bad plan under this scenario, thinking that a value is
unique, using the index - but every tuple in the index has the same
value and each has to be looked up in the table to see if it is visible?
Still, I guess the idea here is not to disable autovacuum, making dead
rows insignificant in the grand scheme of things. I haven't specifically
noticed any performance problems here - PostgreSQL is working great for
me as usual. Just curiosity...
Cheers,
mark
--
Mark Mielke<mark(at)mielke(dot)cc>
From | Date | Subject | |
---|---|---|---|
Next Message | Itagaki Takahiro | 2011-02-05 02:11:22 | Re: multiset patch review |
Previous Message | Bill Pedersen | 2011-02-05 00:48:43 | OpenVMS - an effort which needs guidance and support. |
From | Date | Subject | |
---|---|---|---|
Next Message | Ivan Voras | 2011-02-05 02:50:50 | Re: Query performance with disabled hashjoin and mergejoin |
Previous Message | Bruce Momjian | 2011-02-05 00:17:10 | Re: [HACKERS] Slow count(*) again... |