sing a filter).
>
In both cases the index is returning a lossy bitmap of 59 heap blocks. The
second query is more restrictive, so the number removed by index recheck is
higher. The total of number rows returned plus the number of rows removed
by index recheck is the same in both cases.
The on
On Thu, 20 Jun 2019 at 17:30, Justin Pryzby wrote:
> On Thu, Jun 20, 2019 at 05:18:33PM +0100, Simon Riggs wrote:
> > On Thu, 20 Jun 2019 at 17:01, Chris Wilson <
> [email protected]>
> > wrote:
> >
> >
> > > I deliberately included
erform with just the id column in the index?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
o be happening.
> The execution time also increases massively.
>
>
>
> Could anyone help me to understand what’s going on here, and whether
> there’s a bug or limitation of BRIN indexes? If it’s a limitation, then the
> query planner does not seem to account for it, and chooses this plan even
> when it’s a bad one (much worse than removing result rows using a filter).
>
The second column changes the way the index is defined. It appears there
is very little locality for the r column, so try removing it.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
