On Tue, Nov 5, 2013 at 11:55 PM, Tom Lane wrote:
> Joe Love writes:
>> I'm wondering what type of index would work for this as it is a volatile
>> function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
>> wouldn't be possible or worth doing. It seems to me that all functions i
Joe Love writes:
> I'm wondering what type of index would work for this as it is a volatile
> function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
> wouldn't be possible or worth doing. It seems to me that all functions in
> the "select" part of the statement could be calcula
I'm wondering what type of index would work for this as it is a volatile
function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
wouldn't be possible or worth doing. It seems to me that all functions in
the "select" part of the statement could be calculated at the end of the
quer
Atri Sharma writes:
> I understand the reasons for executing SELECT before the sort. But,
> couldnt we get the planner to see the LIMIT part and push the sort
> node above the select node for this specific case?
[ Shrug... ] I don't see the point. If the OP actually cares about the
speed of thi
On Sat, Nov 2, 2013 at 2:00 AM, Tom Lane wrote:
> Jim Nasby writes:
>> On Oct 31, 2013, at 11:04 AM, Joe Love wrote:
>>> In postgres 9.2 I have a function that is relatively expensive. When I
>>> write a query such as:
>>>
>>> select expensive_function(o.id),o.* from offeirng o where valid='Y'
Jim Nasby-2 wrote
> Should that really matter in this case? ISTM we should always handle LIMIT
> before moving on to the SELECT clause…?
SELECT generate_series(1,10) LIMIT 1
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Feature-request-Optimizer-improvement
On Friday, November 1, 2013, Jim Nasby wrote:
> On Oct 31, 2013, at 2:57 PM, Kevin Grittner
> >
> wrote:
>
> Joe Love 'j...@primoweb.com');>> wrote:
>
> In postgres 9.2 I have a function that is relatively expensive.
>
>
> What did you specify in the COST clause on the CREATE FUNCTION
> statemen
Jim Nasby writes:
> On Oct 31, 2013, at 11:04 AM, Joe Love wrote:
>> In postgres 9.2 I have a function that is relatively expensive. When I
>> write a query such as:
>>
>> select expensive_function(o.id),o.* from offeirng o where valid='Y' order by
>> name limit 1;
> Does anyone know what th
On Oct 31, 2013, at 2:57 PM, Kevin Grittner wrote:
> Joe Love wrote:
>
>> In postgres 9.2 I have a function that is relatively expensive.
>
> What did you specify in the COST clause on the CREATE FUNCTION
> statement?
Should that really matter in this case? ISTM we should always handle LIMIT
On Oct 31, 2013, at 11:04 AM, Joe Love wrote:
> In postgres 9.2 I have a function that is relatively expensive. When I write
> a query such as:
>
> select expensive_function(o.id),o.* from offeirng o where valid='Y' order by
> name limit 1;
>
> the query runs slow and appears to be running th
In postgres 9.2 I have a function that is relatively expensive. When I
write a query such as:
select expensive_function(o.id),o.* from offeirng o where valid='Y' order
by name limit 1;
the query runs slow and appears to be running the function on each ID,
which in this case should be totally unn
Joe Love wrote:
> In postgres 9.2 I have a function that is relatively expensive.
What did you specify in the COST clause on the CREATE FUNCTION
statement?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hacke
In postgres 9.2 I have a function that is relatively expensive. When I
write a query such as:
select expensive_function(o.id),o.* from offeirng o where valid='Y' order
by name limit 1;
the query runs slow and appears to be running the function on each ID,
which in this case should be totally unn
13 matches
Mail list logo
