Re: optimizing a (simple?) query on a largeish table - Mailing list pgsql-novice

From Tom Lane
Subject Re: optimizing a (simple?) query on a largeish table
Date
Msg-id 12440.1195447194@sss.pgh.pa.us
Whole thread Raw
In response to optimizing a (simple?) query on a largeish table  ("Dr. Kurt Ruff" <kurt.ruff@gmail.com>)
List pgsql-novice
"Dr. Kurt Ruff" <kurt.ruff@gmail.com> writes:
> I've got the following query which I'm trying to run on a 4.2 million row table:

> SELECT ActionItems.*
> FROM ActionItems
> WHERE
>     attn=upper(SESSION_USER)
>     or attn in (
>         select upper(groname)
>         from pg_group
>         where (select oid from pg_roles where rolname = SESSION_USER) = ANY(grolist)
>     )
> ORDER BY dateTimeCreated

Replacing the OR with a UNION or UNION ALL might help, though I also
wonder whether you've selected a compatible datatype for "attn".
The upper() calls will yield type TEXT.

[ fools around a bit... ]  Another possibility, if you're using PG 8.2
or later, is to replace the "attn IN (sub-SELECT)" with "attn = ANY
(ARRAY(sub-SELECT))".  This is a hack --- the planner probably ought to
think of that for itself --- but currently it doesn't.

All this advice is predicated on the assumption that there are few
enough matching rows that multiple indexscans really are a better plan
than one seqscan.  Since you didn't say how many rows you expect, it's
not impossible that the plan you've got is in fact the best.

            regards, tom lane

pgsql-novice by date:

Previous
From: "Dr. Kurt Ruff"
Date:
Subject: optimizing a (simple?) query on a largeish table
Next
From: Decibel!
Date:
Subject: Re: populating arrays with default values