From: Alvaro Herrera <alvherre@commandprompt.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgreSQL.org, PostgreSQL Performance <pgsql-performance@postgreSQL.org>
Cc: Steve <cheetah@tanabi.org>
Subject: Re: [HACKERS] choose_bitmap_and again (was Re: Strangely Variable Query Performance)
Date: Fri, 13 Apr 2007 19:24:09 -0400
Message-ID: <20070413232409.GI27255@alvh.no-ip.org> (raw)
In-Reply-To: <26399.1176504501@sss.pgh.pa.us>
References: <Pine.GSO.4.64.0704121855300.17955@kittyhawk.tanabi.org>
<10117.1176420763@sss.pgh.pa.us>
<Pine.GSO.4.64.0704121928440.17955@kittyhawk.tanabi.org>
<10355.1176422445@sss.pgh.pa.us>
<Pine.GSO.4.64.0704122001160.17955@kittyhawk.tanabi.org>
<10503.1176423606@sss.pgh.pa.us>
<Pine.GSO.4.64.0704122025450.17955@kittyhawk.tanabi.org>
<12360.1176436194@sss.pgh.pa.us>
<Pine.GSO.4.64.0704122354430.17955@kit!tyhawk.tanabi.org>
<26399.1176504501@sss.pgh.pa.us>
Tom Lane wrote:
> One idea I thought about was to sort by index scan cost, using
> selectivity only as a tiebreaker for cost, rather than the other way
> around as is currently done. This seems fairly plausible because
> indexscans that are cheaper than other indexscans likely return fewer
> rows too, and so selectivity is already accounted for to some extent ---
> at least you can't have an enormously worse selectivity at lower cost,
> whereas Steve's example proves it doesn't work the other way. But I'm
> worried about breaking the reasoning about redundant indexes that's
> mentioned in the comments.
>
> Another alternative that would respond to the immediate problem is to
> maintain the current sort order, but as we come to each index, consider
> using that one alone, and throw away whatever AND we might have built up
> if that one alone beats the AND-so-far. This seems more conservative,
> as it's unlikely to break any cases that work well now, but on the other
> hand it feels like plastering another wart atop a structure that's
> already rather rickety.
>
> Has anyone got any thoughts about the best way to do this?
How about doing both: sort the index by index scan cost; then pick the
first index on the list and start adding indexes when they lower the
cost. When adding each index, consider it by itself against the
already stacked indexes. If the cost is lower, put this index at the
top of the list, and restart the algorithm (after the sorting step of
course).
I think the concern about condition redundancy should be attacked
separately. How about just comparing whether they have common prefixes
of conditions? I admit I don't understand what would happen with
indexes defined like (lower(A), B, C) versus (A, B) for example.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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-performance@postgresql.org
Cc: alvherre@commandprompt.com, tgl@sss.pgh.pa.us, cheetah@tanabi.org
Subject: Re: [HACKERS] choose_bitmap_and again (was Re: Strangely Variable Query Performance)
In-Reply-To: <20070413232409.GI27255@alvh.no-ip.org>
* 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