Re: Disparity between 8.1.18 and 8.2.14 performance wise - Mailing list pgsql-admin

From Tom Lane
Subject Re: Disparity between 8.1.18 and 8.2.14 performance wise
Date
Msg-id 771.1269361606@sss.pgh.pa.us
Whole thread Raw
In response to Re: Disparity between 8.1.18 and 8.2.14 performance wise  ("Dai, Tino" <tdai@loc.gov>)
List pgsql-admin
"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

pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_stat: last vacuum and analyze times are not being updated - v8.3.5
Next
From: "Bhella Paramjeet-PFCW67"
Date:
Subject: tuning auto vacuum for highly active tables