From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Block level concurrency during recovery |
Date: | 2008-10-23 16:21:48 |
Message-ID: | 4900A49C.1060602@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
> It would also be possible to introduce a special tweak there which is
> that if the block is not in cache, don't read it in at all. If its not
> in cache we know that nobody has a pin on it, so don't need to read it
> in just to say "got the lock". That icing for later.
Heh, that's clever :-). We could actually use a method like that to
solve the whole problem. After the (replay of the) b-tree vacuum is
finished, scan through all shared buffers, and get a vacuum lock on
every page of that index that's in cache. Groveling through all shared
buffers would be slower for small indexes, though.
I believe the "vacuum lock every leaf page" behavior is only needed for
system catalogs. You have other issues with those still, namely that
table locks are not yet taken appropriately, so I'm not sure if this is
worth worrying about until that's done.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2008-10-23 16:21:49 | Re: Unicode escapes in literals |
Previous Message | Tom Lane | 2008-10-23 16:16:16 | Re: Regression in IN( field, field, field ) performance |