Ühel kenal päeval, K, 2006-03-22 kell 17:29, kirjutas Tom Lane:
> Hannu Krosing <hannu@skype.net> writes:
> > Ühel kenal päeval, 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.
Probably true. I can't think of one right now either. And we have
caching to solve these cases.
> 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.
I guess we can't easily start locking some subarea of a page, say 256
byte subpage, or just the tuple.
OTOH it may be possible as we don't need to lock page header for
sequences as the tuple is updated in place and will not change in size.
OTOOH, I'm afraid we still need to WAL the whole page, so the savings
will be marginal.
------------
Hannu