From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: HOT pgbench results |
Date: | 2007-08-07 19:15:13 |
Message-ID: | 1186514113.4192.47.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2007-08-07 at 15:40 +0100, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> >> unpatched HOT
> >> autovacuums 116 43
> >> autoanalyzes 139 60
> >
> >> HOT greatly reduces the number of vacuums needed. That's good, that's
> >> where the gains in throughput in longer I/O bound runs comes from.
> >
> > But surely failing to auto-analyze after a HOT update is a bad thing.
>
> Hmm, I suppose. I don't think we've spend any time thinking about how to
> factor in HOT updates into the autovacuum and autoanalyze formulas yet.
> I'd argue that HOT updates are not as significant as cold ones from
> statistics point of view, though, because they don't change indexed
> columns. HOT-updated fields are not likely used as primary search quals.
I agree with that thought, but the changes to unindexed fields are just
as important for selectivity calculations so we should ANALYZE just as
frequently. ANALYZE is cheap, so we aren't saving anything by avoiding
them.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-08-07 19:15:37 | Re: HOT pgbench results |
Previous Message | Heikki Linnakangas | 2007-08-07 19:14:31 | Re: HOT patch, missing things |