| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Weber, Geoffrey M(dot)" <Geoffrey(dot)Weber(at)mcleodusa(dot)com> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Problem with index not being chosen inside PL/PgSQL function... |
| Date: | 2007-12-18 16:36:06 |
| Message-ID: | 835.1197995766@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"Weber, Geoffrey M." <Geoffrey(dot)Weber(at)mcleodusa(dot)com> writes:
> Hmm - good question! However, it is - both the id and
> not_displayed_id are INTEGERs.
Well, in that case it must be a statistics issue --- does the indexed
column have a badly skewed distribution?
You could investigate how many rows the planner thinks will be fetched
via
PREPARE foo(int) AS
SELECT ah.* FROM alert ah where ( (ah.replaced_by_id = '0') AND (not_displayed_id = $1 ) ) ORDER BY replaced_by_id, not_displayed_id;
EXPLAIN EXECUTE foo(42);
which will set up exactly the same planning situation as occurs in the
plpgsql function: no knowledge of the exact value being compared to.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Weber, Geoffrey M. | 2007-12-18 16:54:54 | Re: Problem with index not being chosen inside PL/PgSQL function... |
| Previous Message | Weber, Geoffrey M. | 2007-12-18 16:28:42 | Re: Problem with index not being chosen inside PL/PgSQL function... |