On Thu, Mar 10, 2011 at 7:32 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> 2010/11/25 pasman pasma?ski :
>> >>I've seen this as well be a performance issue, in particular with
>> >>partitioned tables.
>> >>Out of habit I now write functions that always cache the value of the
>> >>function in
Robert Haas wrote:
> 2010/11/25 pasman pasma?ski :
> >>I've seen this as well be a performance issue, in particular with
> >>partitioned tables.
> >>Out of habit I now write functions that always cache the value of the
> >>function in
> >>a variable and use the variable in the actual query to avo
2010/11/25 pasman pasmański :
>>I've seen this as well be a performance issue, in particular with partitioned
>>tables.
>>Out of habit I now write functions that always cache the value of the
>>function in
>>a variable and use the variable in the actual query to avoid this particular
>>"gotcha".
>I've seen this as well be a performance issue, in particular with partitioned
>tables.
>Out of habit I now write functions that always cache the value of the function
>in
>a variable and use the variable in the actual query to avoid this particular
>"gotcha".
subquery may be used to cache cons
On Nov 24, 2010, at 15:28 , Marti Raudsepp wrote:
> On Wed, Nov 24, 2010 at 21:52, Tom Lane wrote:
>> Bruce Momjian writes:
>>> Notice the to_date()'s were not converted to constants in EXPLAIN so
>>> they are evaluated for every row. to_date() is marked STABLE.
>
>> No. This is per expectat
On Wed, Nov 24, 2010 at 21:52, Tom Lane wrote:
> Bruce Momjian writes:
>> Notice the to_date()'s were not converted to constants in EXPLAIN so
>> they are evaluated for every row. to_date() is marked STABLE.
> No. This is per expectation. Only IMMUTABLE functions can be folded to
> constants
Bruce Momjian writes:
> I realize they can't be converted to constants before the query starts
> but is there a reason we can't convert those functions to constants in
> the executor before a table scan?
Other than the significant number of cycles that would be wasted (in
most cases) checking for
Tom Lane wrote:
> Bruce Momjian writes:
> > Notice the to_date()'s were not converted to constants in EXPLAIN so
> > they are evaluated for every row. to_date() is marked STABLE.
>
> > Is this something we should improve?
>
> No. This is per expectation. Only IMMUTABLE functions can be folded
Bruce Momjian writes:
> Notice the to_date()'s were not converted to constants in EXPLAIN so
> they are evaluated for every row. to_date() is marked STABLE.
> Is this something we should improve?
No. This is per expectation. Only IMMUTABLE functions can be folded to
constants in advance of th
Someone offlist reported query slowness because we don't convert
function calls with all-constant parameters to be a constants before we
start a sequential scan:
EXPLAIN SELECT * FROM test WHERE
x >= to_date('2001-01-01', '-MM-DD') AND
x <= to_date('20
10 matches
Mail list logo
