From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Hannu Krosing <hannu(at)skype(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Accessing schema data in information schema |
Date: | 2006-03-22 23:48:37 |
Message-ID: | 21155.1143071317@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Buttafuoco | 2006-03-23 00:03:56 | create type error message |
Previous Message | Alvaro Herrera | 2006-03-22 23:10:08 | Re: Accessing schema data in information schema |