Re: Disparity between 8.1.18 and 8.2.14 performance wise
От | Dai, Tino |
---|---|
Тема | Re: Disparity between 8.1.18 and 8.2.14 performance wise |
Дата | |
Msg-id | 1CA7FF980DA3824F9A5C31532B7A40DCC4F6C43B@LCXCLMB01.LCDS.LOC.GOV обсуждение исходный текст |
Ответ на | Re: Disparity between 8.1.18 and 8.2.14 performance wise (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Disparity between 8.1.18 and 8.2.14 performance wise
|
Список | pgsql-admin |
> 8.2 was released in 2006. 8.1 is going to be desupported entirely at > the end of 2010. You really need to be holding your vendor's feet to > the fire about supporting modern versions of Postgres, rather than > looking for workarounds. I think that is the correct move. >> 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=43833loops=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? Thanks, Tino
В списке pgsql-admin по дате отправления: