From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: generic plans and "initial" pruning |
Date: | 2022-04-08 11:45:37 |
Message-ID: | CA+HiwqH5gy3FquH1N+mqfU-b0wAZ97Sgeb0maYa0ZQxE6K=vGA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi David,
On Fri, Apr 8, 2022 at 8:16 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Fri, 8 Apr 2022 at 17:49, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > Attached updated patch with these changes.
> Thanks for making the changes. I started looking over this patch but
> really feel like it needs quite a few more iterations of what we've
> just been doing to get it into proper committable shape. There seems
> to be only about 40 mins to go before the freeze, so it seems very
> unrealistic that it could be made to work.
Yeah, totally understandable.
> I started trying to take a serious look at it this evening, but I feel
> like I just failed to get into it deep enough to make any meaningful
> improvements. I'd need more time to study the problem before I could
> build up a proper opinion on how exactly I think it should work.
>
> Anyway. I've attached a small patch that's just a few things I
> adjusted or questions while reading over your v13 patch. Some of
> these are just me questioning your code (See XXX comments) and some I
> think are improvements. Feel free to take the hunks that you see fit
> and drop anything you don't.
Thanks a lot for compiling those.
Most looked fine changes to me except a couple of typos, so I've
adopted those into the attached new version, even though I know it's
too late to try to apply it. Re the XXX comments:
+ /* XXX why would pprune->rti_map[i] ever be zero here??? */
Yeah, no there can't be, was perhaps being overly paraioid.
+ * XXX is it worth doing a bms_copy() on glob->minLockRelids if
+ * glob->containsInitialPruning is true?. I'm slighly worried that the
+ * Bitmapset could have a very long empty tail resulting in excessive
+ * looping during AcquireExecutorLocks().
+ */
I guess I trust your instincts about bitmapset operation efficiency
and what you've written here makes sense. It's typical for leaf
partitions to have been appended toward the tail end of rtable and I'd
imagine their indexes would be in the tail words of minLockRelids. If
copying the bitmapset removes those useless words, I don't see why we
shouldn't do that. So added:
+ /*
+ * It seems worth doing a bms_copy() on glob->minLockRelids if we deleted
+ * bit from it just above to prevent empty tail bits resulting in
+ * inefficient looping during AcquireExecutorLocks().
+ */
+ if (glob->containsInitialPruning)
+ glob->minLockRelids = bms_copy(glob->minLockRelids)
Not 100% about the comment I wrote.
--
Amit Langote
EDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
v14-0001-Optimize-AcquireExecutorLocks-to-skip-pruned-par.patch | application/octet-stream | 99.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2022-04-08 11:47:20 | Re: Expose JIT counters/timing in pg_stat_statements |
Previous Message | Peter Eisentraut | 2022-04-08 11:38:48 | Re: Extract epoch from Interval weird behavior |