Re: Accessing schema data in information schema

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

In response to

Browse pgsql-hackers by date

  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