From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: HOT updates in index-less tables |
Date: | 2010-11-13 18:42:36 |
Message-ID: | 8191.1289673756@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)2ndQuadrant(dot)com> writes:
> On Sat, 2010-11-13 at 12:13 -0500, Tom Lane wrote:
>> 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 ?
I think it's problematic, because heap_page_prune can be executed with
only AccessShareLock on the table, which means there's a race condition
against concurrent CREATE INDEX. You could look at relhasindex easily
enough, but that doesn't prove there's not a CREATE INDEX in progress.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2010-11-13 18:44:25 | Re: wCTE behaviour |
Previous Message | Hannu Krosing | 2010-11-13 18:27:52 | Re: HOT updates in index-less tables |