Re: 8.3devel slower than 8.2 under read-only load
От | Tom Lane |
---|---|
Тема | Re: 8.3devel slower than 8.2 under read-only load |
Дата | |
Msg-id | 23238.1196099300@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 8.3devel slower than 8.2 under read-only load (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: 8.3devel slower than 8.2 under read-only load
|
Список | pgsql-hackers |
Gregory Stark <stark@enterprisedb.com> writes: > A 5-line patch which improves performance by 40% for any case sounds amazing, > but how fragile is that gain? The kind of thing which would be worryign is if > runing a query which uses both varchar and some other ambiguous operator > causes it to lose all its gain. Yeah, exactly. If we're going to risk anything like this at all, the cache-of-one restriction is simply not acceptable (especially given that the part of the coding it would eliminate is the simplest and easiest-to-get-right part). In the test case Guillame provided, every single WHERE clause happens to be of the formvarchar_column = 'unknown-type literal' and there are no other operators used in the SELECT lists; but I can hardly believe that this is representative of any significant number of real-world applications. Even pgbench uses more than one operator. regards, tom lane
В списке pgsql-hackers по дате отправления: