From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "Hannu Krosing" <hannu(at)skype(dot)net> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Luke Lonergan" <llonergan(at)greenplum(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "Eng" <eng(at)intranet(dot)greenplum(dot)com> |
Subject: | Re: old synchronized scan patch |
Date: | 2006-12-05 10:38:08 |
Message-ID: | 45754C10.7030101@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hannu Krosing wrote:
> Ühel kenal päeval, E, 2006-12-04 kell 21:46, kirjutas Tom Lane:
>> Jeff Davis <pgsql(at)j-davis(dot)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.
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2006-12-05 11:00:11 | Re: old synchronized scan patch |
Previous Message | Zeugswetter Andreas ADI SD | 2006-12-05 10:28:22 | Re: old synchronized scan patch |