Skip site navigation (1) Skip section navigation (2)

Re: same plan, add 1 condition, 1900x slower

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mitchell Skinner <mitch(at)egcrc(dot)net>
Cc: Richard Huxton <dev(at)archonet(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: same plan, add 1 condition, 1900x slower
Date: 2005-11-11 17:16:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Mitchell Skinner <mitch(at)egcrc(dot)net> writes:
> On Fri, 2005-11-11 at 10:53 -0500, Tom Lane wrote:
>> what you need to do is incorporate the "source" value into the
>> external_id_map index key somehow.  Then the index scan would be able to
>> realize that there is no possibility of finding another row with source
>> = 'SCH'.  The simplest way is just to make a 2-column index

> I thought that's what I had done with the
> external_id_map_source_target_id index:
>     "external_id_map_source_target_id" btree (source, target_id)

> If I changed that index to be (target_id, source) would it make a difference?

[ fools around with a test case ... ]  Seems like not :-(.  PG is not
bright enough to realize that an index on (source, target_id) can be
used with a mergejoin on target_id, because the index sort order isn't
compatible.  (Given the equality constraint on source, there is an
effective compatibility.  I had thought that 8.1 might be able to
detect this, but it seems not to in a simple test case --- there may be
a bug involved there.  In any case 8.0 definitely won't see it.)  An
index on (target_id, source) would be recognized as mergejoinable, but
that doesn't solve the problem because an index condition on the second
column doesn't provide enough information to know that the scan can stop

Given your comment that the correlation is accidental, it may be that
there's not too much point in worrying.  The planner is picking this
plan only because it notices the asymmetry in key ranges, and as soon
as some more rows get added with higher-numbered target_ids it will
shift to something else (probably a hash join).

			regards, tom lane

In response to

pgsql-performance by date

Next:From: DWDate: 2005-11-11 19:16:01
Subject: slow queries after ANALYZE
Previous:From: Mitchell SkinnerDate: 2005-11-11 16:57:35
Subject: Re: same plan, add 1 condition, 1900x slower

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group