pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-patches@postgreSQL.org
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Steve <cheetah@tanabi.org>
Subject: Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance)
Date: Sat, 14 Apr 2007 18:02:53 -0400
Message-ID: <23414.1176588173@sss.pgh.pa.us> (raw)
In-Reply-To: <7772.1176574886@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>
	<20070413232409.GI27255@alvh.no-ip.org>
	<7772.1176574886@sss.pgh.pa.us>

I wrote:
> Thinking more about this leads me to the following proposal:

> 1. Explicitly group the indexes according to the subset of
> WHERE-conditions (and partial index conditions, if any) they use.
> Within each such group, discard all but the cheapest-scan-cost one.

> 2. Sort the remaining indexes according to scan cost.

> 3. For each index in order, consider it as a standalone scan, and also
> consider adding it on to the AND-group led by each preceding index,
> using the same logic as now: reject using any WHERE-condition twice
> in a group, and then add on only if the total cost of the AND-group
> scan is reduced.

Here is a patch along these lines, in fact two patches (HEAD and 8.2
versions).  The 8.2 version picks up some additional partial-index
intelligence that I added to HEAD on Mar 21 but did not at that time
risk back-patching --- since this is a fairly large rewrite of the
routine, keeping the branches in sync seems best.

Steve, can you try this out on your queries and see if it makes better
or worse decisions?  It seems to fix your initial complaint but I do
not have a large stock of test cases to try.

			regards, tom lane

view thread (10+ messages)  latest in thread

Message-ID: <23414.1176588173@sss.pgh.pa.us>
Permalink:  ../23414.1176588173@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/23414.1176588173@sss.pgh.pa.us

 · 

reply
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: tgl@sss.pgh.pa.us, pgsql-patches@postgreSQL.org, alvherre@commandprompt.com, cheetah@tanabi.org
  Subject: Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance)
  In-Reply-To: <23414.1176588173@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