Re: min()/max() with BRIN indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Wayne <lists-pgsql(at)useunix(dot)net>
Cc: pgsql-sql(at)lists(dot)postgresql(dot)org
Subject: Re: min()/max() with BRIN indexes
Date: 2020-02-29 19:37:15
Message-ID: 16370.1583005035@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Wayne <lists-pgsql(at)useunix(dot)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

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Wayne 2020-02-29 21:40:58 Re: min()/max() with BRIN indexes
Previous Message Wayne 2020-02-29 16:50:24 min()/max() with BRIN indexes