From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Ashwin Agrawal <aagrawal(at)pivotal(dot)io> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Kevin Grittner <kgrittn(at)gmail(dot)com> |
Subject: | Re: An out-of-date comment in nodeIndexonlyscan.c |
Date: | 2021-06-13 12:01:48 |
Message-ID: | CA+hUKGLs7BGFj15by70aykxAJL0SG2zg3S_DbFtZcbRqumpJdg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jun 12, 2021 at 2:35 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> ... and here is the corresponding code change, with a test to
> demonstrate the change.
>
> I'm working on a proof-of-concept to skip the btree page lock
> sometimes too, which seems promising, but it requires some planner
> work which has temporarily pretzeled my brain.
Here's a highly experimental patch I came up with that seems to
produce the right results in simple cases, without (yet) involving the
planner. The regression tests show single table queries, but it works
also for nest loop joins, which is where this optimisation should be
most interesting, I think. There are a few weird things about this
patch though, and there could well be much better ways to do it, as
noted in the commit message and comments. It's a start on the
problem...
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Use-tuple-level-SIREAD-locks-for-index-only-scans.patch | text/x-patch | 6.7 KB |
v2-0002-WIP-Skip-SIREAD-locks-on-btree-pages-when-possibl.patch | text/x-patch | 32.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2021-06-13 12:26:19 | Re: unnesting multirange data types |
Previous Message | Alexander Korotkov | 2021-06-13 11:48:10 | Re: doc issue missing type name "multirange" in chapter title |