To: "Dai, Tino" <tdai@loc.gov>
cc: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Re: Disparity between 8.1.18 and 8.2.14 performance wise 
In-reply-to: <1CA7FF980DA3824F9A5C31532B7A40DCC4F6C43B@LCXCLMB01.LCDS.LOC.GOV>
References: <1CA7FF980DA3824F9A5C31532B7A40DCC4B87E10@LCXCLMB01.LCDS.LOC.GOV>
	<16222.1269299255@sss.pgh.pa.us>
	<1CA7FF980DA3824F9A5C31532B7A40DCC4F6C43B@LCXCLMB01.LCDS.LOC.GOV>
Comments: In-reply-to "Dai, Tino" <tdai@loc.gov>
	message dated "Tue, 23 Mar 2010 11:22:13 -0400"
Date: Tue, 23 Mar 2010 12:26:46 -0400
Message-ID: <771.1269361606@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Dai, Tino" <tdai@loc.gov> writes:
>>> But having said that, I think 8.1 might generate a reasonable plan if it
>>> weren't getting misled by these useless constraints:

>>> ->  Seq Scan on role_setting  (cost=0.00..964.50 rows=1 width=70) (actual time=0.036..121.443 rows=43833 loops=1)
>>> Filter: (((section)::text = (section)::text) AND (ref_id = ref_id))

>> Can you get rid of those?

> Unfortunately, I can't. The third-party product is protected by some kind of
> obfuscation program. :( But is there any kind of external query rewrite tool 
> that can be put in front of postgres? 

Can't think of anything that would be useful for that.  But you could
possibly modify eqsel() so that it checks for the two inputs being
equal() and returns a more reasonable selectivity for that case.
We don't do that by default because it'd usually be a waste of cycles;
but if you're dealing with an application that likes to generate such
clauses, it'd be worth your time.

			regards, tom lane