Re: old synchronized scan patch

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

In response to

Responses

Browse pgsql-hackers by date

  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