I ran both many times and got the same result. ::shrug::
On Thu, Jun 20, 2019 at 12:09:13PM -0600, Michael Lewis wrote:
> For kicks I tried the example given and got the below which seems more
> expected.
Do you just mean that it ran faster the 2nd time ? Isn't that just due just to
cache effects ? Rerun them both back to back.
See that the "actual"
For kicks I tried the example given and got the below which seems more
expected.
explain analyze select * from brin_test where id >= 9;
Bitmap Heap Scan on brin_test (cost=5.78..627.36 rows=9861 width=8)
(actual time=0.373..7.309 rows=10001 loops=1)
Recheck Cond: (id >= 9)
Rows Remo
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 <
> chris.wil...@cantabcapital.com>
> > wrote:
> >
> >
> > > I deliberately included r in the index, to demonstrate the issue that
> I’m
On Thu, Jun 20, 2019 at 05:18:33PM +0100, Simon Riggs wrote:
> On Thu, 20 Jun 2019 at 17:01, Chris Wilson
> wrote:
>
>
> > I deliberately included r in the index, to demonstrate the issue that I’m
> > seeing. I know that there is very little locality in this particular,
> > dummy, arbitrary test
On Thu, 20 Jun 2019 at 17:01, Chris Wilson
wrote:
> I deliberately included r in the index, to demonstrate the issue that I’m
> seeing. I know that there is very little locality in this particular,
> dummy, arbitrary test case. I can try to produce a test case that has some
> locality, but I exp
Hi Simon,
I deliberately included r in the index, to demonstrate the issue that I’m
seeing. I know that there is very little locality in this particular, dummy,
arbitrary test case. I can try to produce a test case that has some locality,
but I expect it to show exactly the same results, i.e. t
On Thu, 20 Jun 2019 at 16:13, Chris Wilson
wrote:
> Dear Postgres performance experts,
>
>
>
> I noticed that when I added a BRIN index to a very large table, attempting
> to make a particular query faster, it became much slower instead. While
> trying to understand this, I noticed that the actua
Dear Postgres performance experts,
I noticed that when I added a BRIN index to a very large table, attempting to
make a particular query faster, it became much slower instead. While trying to
understand this, I noticed that the actual number of rows in the EXPLAIN
ANALYZE output was much higher
