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 по дате отправления: