From: | Andrew McMillan <andrew(at)catalyst(dot)net(dot)nz> |
---|---|
To: | Jan Aerts <jan(dot)aerts(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: index on custom function; explain |
Date: | 2005-10-06 18:50:01 |
Message-ID: | 1128624601.17294.86.camel@lamb.mcmillan.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, 2005-10-04 at 03:10 -0700, Jan Aerts wrote:
> Some additional thoughts: what appears to take the most time (i.e.
> account for the highest cost in the explain), is _not_ running the
> function itself (cost=0.00..0.01), but comparing the result from that
> function with the name1 column in the mappings table
> (cost=0.00..35935.05). Am I right? (See EXPLAIN in previous post.) If
> so: that's pretty strange, because the name1-column in the mappings
> table is indexed...
35935.05 is for the loop, 0.01 is for the operation within the loop.
What version of PostgreSQL is this? Some old versions were not good at
handling the IN ( ... ) clause.
Also, PostgreSQL doesn't always do a wonderful job of considering the
activities of a function into the design of the query plans. Sometimes
this can be a blessing, but not in this case.
Cheers,
Andrew.
-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267
It is truth which you cannot contradict; you can without any difficulty
contradict Socrates. - Plato
-------------------------------------------------------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2005-10-06 19:46:06 | Re: functions and execution plan caching |
Previous Message | Martijn van Oosterhout | 2005-10-06 16:57:30 | Re: [PERFORM] A Better External Sort? |