Re: Accessing schema data in information schema

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Hannu Krosing <hannu@skype.net>, Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Date: 2006-03-22T23:48:37Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> 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