Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hannu Krosing wrote:
>> I guess we can't easily start locking some subarea of a page, say 256
>> byte subpage, or just the tuple.
> Huh, we _can_ lock individual tuples, using LockTuple() (or rather,
> heap_lock_tuple). Since the tuple is modified in place, there's no need
> to lock the whole page.
But heap_lock_tuple is pretty expensive and subject to deadlocks. I
think getting the buffer content lock on the page will still be the
right thing.
>> OTOOH, I'm afraid we still need to WAL the whole page, so the savings
>> will be marginal.
> Huh, why? We can just keep the current WAL logging for sequences, or
> something very similar, can't we?
In the case of the first touch of a sequence page after checkpoint, we'd
need to WAL the whole page image to defend against page breaks during
write. After that though the WAL entries would be *smaller* than they
are now, since there'd be no need to log the entire content of the
changed tuple; we'd know we only need to log the counter advance.
It's hard to say whether this'd be a win, loss, or wash without testing.
It'd probably depend on how many nextval's per checkpoint you want to
assume.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
