Re: Understanding BRIN index performance - Mailing list pgsql-performance

From Ivan Voras
Subject Re: Understanding BRIN index performance
Date
Msg-id CAF-QHFXaWNHiR_rz2iV7z=9pGgnxNUf9OLn+024ktbEMqQ4OQQ@mail.gmail.com
Whole thread Raw
In response to Re: Understanding BRIN index performance  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-performance
On 3 October 2016 at 12:05, Simon Riggs <simon@2ndquadrant.com> wrote:
On 3 October 2016 at 10:58, Ivan Voras <ivoras@gmail.com> wrote:

> I get that, my question was more about why the index scan returned 25 mil
> rows, when the pages are sequentially filled by timestamps? In my
> understading of BRIN, it should have returned a small number of pages which
> would have been filtered (and sorted) for the exact data, right?

That could be most simply explained if the distribution of your data
is not what you think it is.


Something doesn't add up.
I've clustered the table, then created a BRIN index, and the number of rows resulting from the index scan dropped only very slightly.

Hmmm, looking at your original reply about the metadata, and my query, did you mean something like this:

SELECT id FROM expl_transactions WHERE dateAdded < (now() - INTERVAL '10 MINUTES') ORDER BY dateAdded DESC LIMIT 1

To solve this with a BRIN index, the index records (range pairs?) themselves would need to be ordered, to be able to perform the "ORDER by ... DESC" operation with the index, and then sort it and take the single record from this operation, and there is currently no such data being recorded?




pgsql-performance by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Understanding BRIN index performance
Next
From: Gavin Flower
Date:
Subject: Re: MYSQL Stats