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
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 |