Re: Predicate locking - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Predicate locking
Date
Msg-id 4DC06EAD020000250003D213@gw.wicourts.gov
Whole thread Raw
In response to Re: Predicate locking  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: Predicate locking  (Greg Smith <greg@2ndquadrant.com>)
Re: Predicate locking  (Greg Smith <greg@2ndquadrant.com>)
Re: Predicate locking  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Greg Smith <greg@2ndquadrant.com> wrote:
> However, if I increase the generate_series to create 349 rows (or
> more) instead, it works.

> I don't fully understand why this attempt I tried to do that is
> working the way it does though.
Check where the plan goes from a table scan to an indexed access.
Also look at what is showing for SIRead locks in pg_locks as you go.
Between those two bits of information, it should become apparent.
> I don't think Vlad is being unreasonable here; he's provided a
> test case demonstrating the behavior he'd like to see, and shown
> it doesn't work as expected.
... on a toy table with contrived values.  How different is this
from the often-asked question about why a query against a four-line
table is not using the index they expect, and how can we expect it
to scale if it doesn't?  I agree that it's not unreasonable for
someone to ask either question.  If my response falls short, I'm
game to try again.
-Kevin


pgsql-hackers by date:

Previous
From: David Blewett
Date:
Subject: Re: branching for 9.2devel
Next
From: David Blewett
Date:
Subject: Re: branching for 9.2devel