Re: HOT updates in index-less tables

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: HOT updates in index-less tables
Date: 2010-11-13 18:27:52
Message-ID: 1289672872.11116.324.camel@hvost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 2010-11-13 at 12:13 -0500, Tom Lane wrote:
> Hannu Krosing <hannu(at)2ndQuadrant(dot)com> writes:
> > On Sat, 2010-11-13 at 10:51 -0500, Tom Lane wrote:
> >> If a table has no indexes, we will always decide that any same-page
> >> update operation is a HOT update, since obviously it isn't modifying
> >> any indexed columns. But is there any benefit to doing so?
>
> > If we do the in-page "mini vacuum" even without HOT, then there should
> > be no benefit from index-less HOT updates.
>
> AFAICS we do: heap_update marks the page as prunable whether it's a HOT
> update or not. The only difference between treating the update as HOT vs
> not-HOT is that if there was more than one HOT update, the intermediate
> tuples could be completely reclaimed by page pruning (ie, their line
> pointers go away too). With not-HOT updates, the intermediate line
> pointers would have to remain in DEAD state until vacuum,

How hard would it be to make the pruning logic be aware of there being
no indexes and thus no possibility of index entries pointing at any
tuple ?

> since page
> pruning wouldn't know if there were index entries pointing at them.
> But that seems like a pretty tiny penalty.
>
> regards, tom lane

--
-------
Hannu Krosing
PostgreSQL Infinite Scalability and Performance Consultant
PG Admin Book: http://www.2ndQuadrant.com/books/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-11-13 18:42:36 Re: HOT updates in index-less tables
Previous Message Peter Eisentraut 2010-11-13 18:07:42 Re: [COMMITTERS] pgsql: Improved parallel make support