From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Hannu Krosing <hannu(at)skype(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-06 18:48:03 |
Message-ID: | 20061206184803.GM44124@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 05, 2006 at 09:09:39AM -0800, Jeff Davis wrote:
> That being said, I can just lock the hint table (the shared memory hint
> table, not the relation) and only update the hint every K pages, as Niel
> Conway suggested when I first proposed it. If we find a K small enough
> so the feature is useful, but large enough that we're sure there won't
> be contention, this might be a good option. However, I don't know that
> we would eliminate the contention, because if K is a constant (rather
> than random), the backends would still all want to update that shared
> memory table at the same time.
What about some algorithm where only one backend will update the hint
entry (perhaps the first one, or the slowest one (ie: lowest page
number))? ISTM that would eliminate a lot of contention, and if you get
clever with the locking scheme you could probably allow other backends
to do non-blocking reads except when the page number passes a 4-byte
value (assuming 4-byte int updates are atomic).
Granted, coming up with a way to put one backend in charge of this is
non-trivial, but it's another option.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-12-06 18:51:03 | Re: psql return codes |
Previous Message | Teodor Sigaev | 2006-12-06 18:41:43 | Re: Bundle of patches |