Re: postgres 7.4 vs 8.x redux: query plans

From: Tom Lane
Subject: Re: postgres 7.4 vs 8.x redux: query plans
Date: ,
Msg-id: 12660.1175635265@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher")
Responses: Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher")
Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher")
Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher")
List: pgsql-performance

Tree view

postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher", )
 Re: postgres 7.4 vs 8.x redux: query plans  (Tom Lane, )
  Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher", )
   Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher", )
    Re: postgres 7.4 vs 8.x redux: query plans  ("Merlin Moncure", )
     Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher", )
      Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher", )
       Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher", )
       Re: postgres 7.4 vs 8.x redux: query plans  (Tom Lane, )
        Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher", )
        Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher", )
        Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher", )
         Re: postgres 7.4 vs 8.x redux: query plans  ("Alex Deucher", )

"Alex Deucher" <> writes:
> Turning off bitmapscan ends up doing a sequential scan.  Turning off
> both bitmapscan and seqscan results in a bitmap heap scan.  It doesn't
> seem to want to use the index at all.  Any ideas?

The "ORed indexscans" plan style that was in 7.4 isn't there anymore;
we use bitmap OR'ing instead.  There actually are repeated indexscans
hidden under the "= ANY" indexscan condition in 8.2, it's just that
the mechanism for detecting duplicate matches is different.  AFAIK the
index access costs ought to be about the same either way, and the other
costs the same or better as what we did in 7.4.  It's clear though that
8.2 is taking some kind of big hit in the index access in your case.
There's something very strange going on here.

You do have both lc_collate and lc_ctype set to C, right?  What about
database encoding?

            regards, tom lane


pgsql-performance by date:

From: Geoff Tolley
Date:
Subject: Re: SCSI vs SATA
From: "Brian A. Seklecki"
Date:
Subject: Re: SCSI vs SATA