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

From: "Alex Deucher" <alexdeucher(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Merlin Moncure" <mmoncure(at)gmail(dot)com>, "PostgreSQL Performance" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: postgres 7.4 vs 8.x redux: query plans
Date: 2007-04-03 21:43:47
Message-ID: a728f9f90704031443o7f2bfbbfy69439d069ccf5496@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 4/3/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Alex Deucher" <alexdeucher(at)gmail(dot)com> 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?
>

Also for reference, the old 7.4 DB is C for lc_collate and lc_ctype
and SQL_ASCII for encoding.

Alex

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Craig A. James 2007-04-03 21:47:30 Re: [HACKERS] EXISTS optimization
Previous Message Alex Deucher 2007-04-03 21:38:34 Re: postgres 7.4 vs 8.x redux: query plans