Re: HOT pgbench results
От | Mark Mielke |
---|---|
Тема | Re: HOT pgbench results |
Дата | |
Msg-id | 46B8A3FD.6010607@mark.mielke.cc обсуждение исходный текст |
Ответ на | Re: HOT pgbench results (Heikki Linnakangas <heikki@enterprisedb.com>) |
Список | pgsql-hackers |
Heikki Linnakangas wrote: <blockquote cite="mid:46B8844C.2050506@enterprisedb.com" type="cite"><pre wrap="">Tom Lane wrote:</pre><blockquote type="cite"><pre wrap="">Heikki Linnakangas <a class="moz-txt-link-rfc2396E" href="mailto:heikki@enterprisedb.com"><heikki@enterprisedb.com></a>writes: </pre><blockquote type="cite"><pre wrap="">HOTgreatly reduces the number of vacuums needed. That's good, that's where the gains in throughput in longer I/O bound runs comes from. </pre></blockquote><pre wrap="">But surely failingto auto-analyze after a HOT update is a bad thing. </pre></blockquote><pre wrap=""> 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. </pre></blockquote> Even for fields that are usedin primary searches, HOT updates avoid changing the disk block layout, and as reading from the disk is usually the mostexpensive operation, the decisions shouldn't change much before and after a HOT update compared to before and after aregular update.<br /><br /> Cheers,<br /> mark<br /><br /><pre class="moz-signature" cols="72">-- Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a> </pre>
В списке pgsql-hackers по дате отправления: