From: | Mark Mielke <mark(at)mark(dot)mielke(dot)cc> |
---|---|
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 16:55:25 |
Message-ID: | 46B8A3FD.6010607@mark.mielke.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> Tom Lane wrote:
>
>> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>>
>>> 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.
>
Even for fields that are used in primary searches, HOT updates avoid
changing the disk block layout, and as reading from the disk is usually
the most expensive operation, the decisions shouldn't change much before
and after a HOT update compared to before and after a regular update.
Cheers,
mark
--
Mark Mielke <mark(at)mielke(dot)cc>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-08-07 17:12:18 | Re: More logging for autovacuum |
Previous Message | Joshua D. Drake | 2007-08-07 15:39:52 | Re: More logging for autovacuum |