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
Date: Sun, 16 Oct 2022 10:41:57 -0400
Message-ID: <1698651.1665931317@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, tomas.vondra@enterprisedb.com, pgsql-hackers@lists.postgresql.org
Subject: Re: PATCH: Using BRIN indexes for sorted output
In-Reply-To: <1698651.1665931317@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox