From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: PATCH: Using BRIN indexes for sorted output
In-reply-to: <1a7c2ff5-a855-64e9-0272-1f9947f8a558@enterprisedb.com>
References: <e70fa091-e338-1598-9de4-6d0ef6b693e2@enterprisedb.com>
 <1a7c2ff5-a855-64e9-0272-1f9947f8a558@enterprisedb.com>
Comments: In-reply-to Tomas Vondra <tomas.vondra@enterprisedb.com>
	message dated "Sun, 16 Oct 2022 15:50:53 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1698650.1665931317.1@sss.pgh.pa.us>
Date: Sun, 16 Oct 2022 10:41:57 -0400
Message-ID: <1698651.1665931317@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1698651.1665931317%40sss.pgh.pa.us>
Precedence: bulk

Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> I forgot to mention one important issue in my list yesterday, and that's
> memory consumption.

TBH, this is all looking like vastly more complexity than benefit.
It's going to be impossible to produce a reliable cost estimate
given all the uncertainty, and I fear that will end in picking
BRIN-based sorting when it's not actually a good choice.

The examples you showed initially are cherry-picked to demonstrate
the best possible case, which I doubt has much to do with typical
real-world tables.  It would be good to see what happens with
not-perfectly-sequential data before even deciding this is worth
spending more effort on.  It also seems kind of unfair to decide
that the relevant comparison point is a seqscan rather than a
btree indexscan.

			regards, tom lane