On Sat, Feb 29, 2020 at 02:37:15PM -0500, Tom Lane wrote:
> Wayne <lists-pgsql@useunix.net> writes:
> > I have rather large tables that use a time stamp as an index. New entries
> > are continuously added to the table with the current time. If I convert
> > from BTREE to BRIN indexes and select records with specific date ranges
> > the BRIN is used and performance is acceptable. However I often want to
> > get the latest time stamp using the max() function. I didn't expect that
> > this would result in a sequential scan of the table and skip the BRIN
> > index.
>
> > Is this expected behavior?
>
> Yeah. In principle a BRIN index could be used to accelerate finding min
> or max, but there's no actual support for that at the moment ... and in
> any case, it'd still be substantially slower than the equivalent with
> a btree index, which can locate the extremal values immediately.
>
> For this particular case, you might be able to fake it with something like
>
> select max(ts) from mytab where ts > 'some cutoff'
>
> if you can estimate some not-too-far-before-current-time cutoff
> that you are sure you'll find some records after.
>
> regards, tom lane
>
Thanks Tom,
I kind of "discovered" the 'some cutoff' trick prior to my posting but
neglected to mention it as I couldn't figure out why it worked but
max(ts) by itself wouldn't.
Agreed, it would be substantially slower than a btree index but much
faster than a seq scan of the table. In this use case they are monthly
tables typically >= 130gig. The btree index is typically >20 gig while
the corresponding brin is ~ 2meg. For all other use cases on these
tables the brin index is a great space vs performance compromise.
For now I can get by with the 'some cutoff' estimate but I hope adding
min()/max() to brin indexes on the wish list.
Thanks again,
Wayne