On Thu, 22 Jul 2021 at 01:54, David Rowley wrote:
> Maybe the planner would need to be involved in making the decision of
> if the bitmap index scan should tuck away a carbon copy of the
> resulting TIDBitmap after the first scan. That way on rescan we could
> just make a copy of the cached versi
On Wed, 21 Jul 2021 at 13:32, Tom Lane wrote:
>
> David Rowley writes:
> > I imagined Jeff was meaning the bitmap from the scan of foo_x_idx, not
> > the combined ANDed bitmap from both indexes.
>
> To re-use that, you'd need a way to prevent the upper node from
> destructively modifying the tidb
David Rowley writes:
> On Wed, 21 Jul 2021 at 11:25, Tom Lane wrote:
>> 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 b
On Wed, 21 Jul 2021 at 11:25, Tom Lane wrote:
>
> Jeff Janes 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)
>
>
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)
drop table if exists foo;
create table foo (x daterange, i int, t text);
insert into f
Jeff Janes 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
