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