On Tue, 2010-01-05 at 13:47 -0600, Kevin Grittner wrote:
> I will not
> spend any significant amount of time looking at the specifics of any
> particular optimizations yet, because such premature optimization is
> certain to kill the whole project.
I'm certainly not trying to derail the project, I'm just trying to see
some light at the end of the tunnel.
Is a full table lock acceptable in the end? If so, then predicate
locking is just optimization, and we should leave it until later.
If not, then reasonably efficient predicate locking is a part of the
design. We can still leave it until later, but we shouldn't call design
issues "premature optimization".
> I don't yet know a lot about GiST indexes beyond the high-level
> theory (it's an area where I haven't yet delved into the code), but
> it's pretty easy to get to page level locks if (and only if) an
> index search is guaranteed to look at some page which will be
> modified if a later conflicting INSERT or UPDATE will be required to
> modify either that page or a logically adjacent page. My initial
> intuition is that a search can't decide that there are no matching
> rows unless it has looked at some page which would be different if a
> matching row existed.
Well, that's my concern. Technically, I think you're correct. But that
might not be very helpful in the case of GIN fastupdate, for instance.
Every insert will modify the fastupdate buffer, and every search will
read it.
> > One approach that might work for GiST is to get some kind of lock
> > (SIREAD?) on the predicates for the pages that the search does not
> > match. That way, the conflict can be detected if an INSERT tries
> > to update the predicate of a page to something that the search may
> > have matched.
>
> That sounds right to me.
With GiST, the picture looks a little more promising. I'm still a little
concerned that it will cause significant performance pitfalls, however.
> I
> think there are obvious down-sides to such a strategy, so I'm forced
> into the position of saying, with regards to most potential
> optimizations, "we'll cross that bridge when we come to it" --
> knowing full well that many optimizations will indeed be necessary
> before the patch is acceptable.
That's fine with me, and I'll hold off on issues like this one.
Regards,Jeff Davis
