On Tue, Mar 1, 2011 at 2:51 AM, Orhan Kavrakoglu wrote:
>> I would like to know if there is a way in PostgreSQL to avoid repeating an
>> expensive computation in a SELECT where the result is needed both as a
>> returned value and as an expression in the WHERE clause.
>
> I think I've seen it said
On 2011-02-03 18:07, Bob Price wrote:
I would like to know if there is a way in PostgreSQL to avoid repeating an
expensive computation in a SELECT where the result is needed both as a returned
value and as an expression in the WHERE clause.
I think I've seen it said here that PG avoids redund
avoid repeating expensive computation in select
> To: "Bob Price"
> Cc: "Bill Moran" , pgsql-general@postgresql.org
> Date: Thursday, February 3, 2011, 5:33 PM
> Bob Price
> writes:
> > If I set the COST of expensivefunc high, and label it
> IMMUTABLE, will the
Nicklas =?ISO-8859-1?Q?Av=E9n?= writes:
> I thought the "offset 0" trick was just a dirty hack, but coming from
> you, Tom, I assume it is a robust way of doing it.
Well, I can't deny it's a dirty hack ... but it's not something we'll
break until we have a better solution.
> I also tried some of
Bob Price writes:
> If I set the COST of expensivefunc high, and label it IMMUTABLE, will the
> query executor note that the two invocations to expensivefunc have the same
> inputs so it can only call it once and re-use the result the second time?
No. There is a myth prevalent among certain wi
That's interesting Tom.
This is a discussion coming up sometimes at PostGIS lists since PostGIS
often handles "expensive" calculations.
Regina wrote a blog post about it:
http://postgresonline.com/journal/archives/113-How-to-force-PostgreSQL-to-use-a-pre-calculated-value.html
I thought the "off
ime use function that declared
a variable with this 'constantdata...'::X value, and then pass this variable in
both calls.
Would this work?
Thanks again!
Bob
--- On Thu, 2/3/11, Bill Moran wrote:
> From: Bill Moran
> Subject: Re: [GENERAL] how to avoid repeating expensive com
I have been searching through the docs and mailing list and haven't found a way
to do this, so I thought I would ask the community.
I would like to know if there is a way in PostgreSQL to avoid repeating an
expensive computation in a SELECT where the result is needed both as a returned
value an
Hello
2011/2/3 Tom Lane :
> Bob Price writes:
>> I would like to know if there is a way in PostgreSQL to avoid repeating an
>> expensive computation in a SELECT where the result is needed both as a
>> returned value and as an expression in the WHERE clause.
>
> Use a subselect. You might need
Bob Price writes:
> I would like to know if there is a way in PostgreSQL to avoid repeating an
> expensive computation in a SELECT where the result is needed both as a
> returned value and as an expression in the WHERE clause.
Use a subselect. You might need OFFSET 0 to prevent the planner fro
-general-ow...@postgresql.org] On Behalf Of Bob Price
Sent: Thursday, February 03, 2011 12:18 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] how to avoid repeating expensive computation in select
I have been searching through the docs and mailing list and haven't found a
way to do this,
In response to Bob Price :
> I have been searching through the docs and mailing list and haven't found a
> way to do this, so I thought I would ask the community.
>
> I would like to know if there is a way in PostgreSQL to avoid repeating an
> expensive computation in a SELECT where the result
I have been searching through the docs and mailing list and haven't found a way
to do this, so I thought I would ask the community.
I would like to know if there is a way in PostgreSQL to avoid repeating an
expensive computation in a SELECT where the result is needed both as a returned
value an
13 matches
Mail list logo
