I have an abstract solution for a problem in postgresql's
handling of what should be constant data.
We had problem with a query taking way too long, basically
we had this:
select
date_part('hour',t_date) as hour,
transval as val
from st
where
id = 500
AND hit_date = '2000-12-07
We had problem with a query taking way too long, basically
we had this:
select
date_part('hour',t_date) as hour,
transval as val
from st
where
id = 500
AND hit_date = '2000-12-07 14:27:24-08'::timestamp - '24
hours'::timespan AND hit_date = '2000-12-07
Alfred Perlstein [EMAIL PROTECTED] writes:
Each function should have a marker that explains whether when given
a const input if the output might vary, that way subexpressions can
be collapsed until an input becomes non-const.
We already have that and do that.
The reason the datetime-related
* Tom Lane [EMAIL PROTECTED] [001207 16:45] wrote:
Alfred Perlstein [EMAIL PROTECTED] writes:
Each function should have a marker that explains whether when given
a const input if the output might vary, that way subexpressions can
be collapsed until an input becomes non-const.
We already
Alfred Perlstein [EMAIL PROTECTED] writes:
... However there's a hook mentioned in my abstract that
explains that if a constant makes it into a function, you can
provide a hook so that the function can return whether or not that
constant is cacheable.
Oh, I see --- you're right, I missed
