Ühel kenal päeval, T, 2006-12-05 kell 10:38, kirjutas Heikki
Linnakangas:
> Hannu Krosing wrote:
> > Ühel kenal päeval, E, 2006-12-04 kell 21:46, kirjutas Tom Lane:
> >> Jeff Davis <pgsql@j-davis.com> writes:
> >>> Since I am not storing any pointers, and since the information is only
> >>> really a hint, I don't need to do any locking on that page.
> >> If you think that, you need not bother to submit the patch. (Hint:
> >> as soon as you consider more than one table at a time, it doesn't work,
> >> even ignoring the question of inconsistent reads.)
> >
> > Why does it not work ?
> >
> > Are you suggesting, that another backend can somegow see only some bits
> > of page number being written ?
> >
> > What problems do you see in multiple table case ?
>
> You need to manage adding and removing relations from the shared memory
> structure. Which typically needs locking.
My impression was, that Jeff planned to do simple hashing to one of N
values and to write current page number there, maybe not even page nr
but each M-th page number.
Assuming that writing a 4byte page number is atomic op, then there is no
need for locking
> Assuming that relations are added or removed relatively seldom, you
> might get away with a table of (Oid, BlockNumber) pairs, working around
> the fact that the table might get messed up every now and then, and when
> it does, you'll lose the benefits until it gets corrected. But it seems
> really messy to me.
Just storing page number at offset is cheap (and imho nice and clean
too).
The worst that can happen, is a hash collision, in which case you lose
the benefits of sync scans, but you wont degrade compared to non-sync
scans
--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
