Re: Bitmap reuse

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Bitmap reuse
Date: 2021-07-21 00:31:42
Message-ID: CAApHDvopTfKCFb=s-+s7jEd3T8hLFKNQUser=U_q4StaUV2i-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 21 Jul 2021 at 11:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> > For some queries PostgreSQL can spend most of its time creating the exact
> > same bitmap over and over. For example, in the below case: (also attached
> > as a file because line-wrapping is going to make a mess of it)
>
> Uh .... it's not the "exact same bitmap each time", because the selected
> rows vary depending on the value of g.i.

I imagined Jeff was meaning the bitmap from the scan of foo_x_idx, not
the combined ANDed bitmap from both indexes.

I didn't look in detail, but I'd think it would just be a matter of
caching the bitmap then in ExecReScanBitmapIndexScan(), if the
PlanState's chgParam indicate a parameter has changed, then throw away
the cache. Then if the cache is still valid in
MultiExecBitmapIndexScan(), return it. Not too sure about the memory
context part for the cache. As I said, I didn't look in detail.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-07-21 00:34:12 Re: CLUSTER on partitioned index
Previous Message Michael Paquier 2021-07-21 00:28:09 Re: Micro-optimizations to avoid some strlen calls.