Re: 8.3devel slower than 8.2 under read-only load - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 8.3devel slower than 8.2 under read-only load
Date
Msg-id 23238.1196099300@sss.pgh.pa.us
Whole thread Raw
In response to Re: 8.3devel slower than 8.2 under read-only load  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: 8.3devel slower than 8.2 under read-only load  ("Guillaume Smet" <guillaume.smet@gmail.com>)
List 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 by date:

Previous
From: Gregory Stark
Date:
Subject: Re: 8.3devel slower than 8.2 under read-only load
Next
From: Tom Lane
Date:
Subject: Re: maintenance_work_mem memory constraint?