Re: poor execution plan because column dependence

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Václav Ovsík <vaclav(dot)ovsik(at)i(dot)cz>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: poor execution plan because column dependence
Date: 2011-04-14 14:10:44
Message-ID: 13172.1302790244@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

=?iso-8859-1?Q?V=E1clav_Ovs=EDk?= <vaclav(dot)ovsik(at)i(dot)cz> writes:
> I'm not certain about your sentence touching int4eq() and index. The
> execution plan as show in my previous mail contains information about
> using index tickets5:

> -> Index Scan using tickets5 on tickets main (cost=0.00..4.38 rows=1 width=162) (actual time=0.006..0.006 rows=0 loops=15593)
> Index Cond: (main.id = transactions_1.objectid)
> Filter: (((main.status)::text <> 'deleted'::text) AND (main.lastupdated > '2008-12-31 23:00:00'::timestamp without time zone) AND (main.created > '2005-12-31 23:00:00'::timestamp without time zone) AND int4eq(main.effectiveid, main.id) AND (main.queue = 15) AND ((main.type)::text = 'ticket'::text) AND ((main.status)::text = 'resolved'::text))

> That means tickets5 index was used for int4eq(main.effectiveid, main.id).
> Is it right? Or am I something missing?

No, the clause that's being used with the index is
main.id = transactions_1.objectid
The "filter condition" is just along for the ride --- it doesn't matter
what sort of expressions are in there, so long as they only use
variables available at this point in the plan. But if you had coded
that clause as
int4eq(main.id, transactions_1.objectid)
it would have been unable to create this plan at all.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Carey 2011-04-14 20:05:36 Re: Linux: more cores = less concurrency.
Previous Message Cédric Villemain 2011-04-14 11:29:35 Re: Performance