Re: Accessing schema data in information schema
От | Tom Lane |
---|---|
Тема | Re: Accessing schema data in information schema |
Дата | |
Msg-id | 21155.1143071317@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Accessing schema data in information schema (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: