Re: Block level concurrency during recovery

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

In response to

Responses

Browse pgsql-hackers by date

  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