Re: Disparity between 8.1.18 and 8.2.14 performance wise

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dai, Tino" <tdai(at)loc(dot)gov>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Disparity between 8.1.18 and 8.2.14 performance wise
Date: 2010-03-23 16:26:46
Message-ID: 771.1269361606@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

"Dai, Tino" <tdai(at)loc(dot)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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Bhella Paramjeet-PFCW67 2010-03-23 20:54:37 tuning auto vacuum for highly active tables
Previous Message Tom Lane 2010-03-23 15:43:32 Re: pg_stat: last vacuum and analyze times are not being updated - v8.3.5