Re: Disparity between 8.1.18 and 8.2.14 performance wise

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Disparity between 8.1.18 and 8.2.14 performance wise
Дата
Msg-id 771.1269361606@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Disparity between 8.1.18 and 8.2.14 performance wise  ("Dai, Tino" <tdai@loc.gov>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_stat: last vacuum and analyze times are not being updated - v8.3.5
Следующее
От: "Bhella Paramjeet-PFCW67"
Дата:
Сообщение: tuning auto vacuum for highly active tables