Date: Sat, 29 Feb 2020 21:40:58 +0000
From: Wayne <lists-pgsql@useunix.net>
To: pgsql-sql@lists.postgresql.org
Subject: Re: min()/max() with BRIN indexes
Message-ID: <20200229214058.GE20190@ln-1.useunix.net>
Mail-Followup-To: pgsql-sql@lists.postgresql.org
References: <20200229165024.GD20190@ln-1.useunix.net>
 <16370.1583005035@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16370.1583005035@sss.pgh.pa.us>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

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