| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hannu Krosing <hannu(at)skype(dot)net> |
| Cc: | 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 22:29:08 |
| Message-ID: | 20499.1143066548@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)skype(dot)net> writes:
> hel kenal peval, K, 2006-03-22 kell 16:11, kirjutas Tom Lane:
>> Yeah. I've occasionally toyed with the idea that sequences should be
>> rows in a single catalog instead of independent tables as they are now.
>> This would make for a much smaller disk footprint (with consequent I/O
>> savings) and would solve problems like the one you have.
> Would it not make page locking problems much worse with all get_next()'s
> competeing to update the same page?
Well, there'd be at most about 80 sequences per page (ballpark estimate
remembering that we'd still want to store a sequence name) and the
reduction in demand for shared buffers might outweigh the increased
contention for any one buffer. I haven't seen any examples where get_next
is the key source of contention anyhow. A last point is that in simple
cases where the contention is all on one sequence, you're going to have
that problem anyway.
> At least unless you reserve one page for each sequence.
Which is exactly what I don't want. But we could imagine padding the
tuples to achieve any particular tuples/page ratio we want, if 80 proves
to be uncomfortably many.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2006-03-22 22:48:43 | Re: Accessing schema data in information schema |
| Previous Message | Hannu Krosing | 2006-03-22 22:10:54 | Re: Accessing schema data in information schema |