Hi all,
I am new in this group and need some help from your side.
We have a mediation product which is initially using Oracle as database.
Some of our customer interested to move Postgres 9.1.
Our mediation product storing some configuration related information in data
base and some type of lo
On 08/14/2013 12:17 PM, Tom Lane wrote:
> [ shrug... ] Using IMMUTABLE to lie about the mutability of a function
> (in this case, date_trunc) is a bad idea. It's likely to lead to wrong
> answers, never mind performance issues. In this particular case, I
> imagine the performance problem comes f
Craig Ringer writes:
> I've run into an interesting Stack Overflow post where the user shows
> that marking a particular function as IMMUTABLE significantly hurts the
> performance of a query.
> http://stackoverflow.com/q/18220761/398670
> CREATE OR REPLACE FUNCTION
> to_datestamp_immutable(ti
On 08/14/2013 11:52 AM, Pavel Stehule wrote:
>
> If I understand, a used IMMUTABLE flag disables inlining. What you see,
> is SQL eval overflow.
>
> My rule is - don't use flags in SQL functions, when it is possible.
Interesting. I knew that was the case for STRICT, but am surprised to
hear it's
2013/8/14 Craig Ringer
> Hi folks
>
> I've run into an interesting Stack Overflow post where the user shows
> that marking a particular function as IMMUTABLE significantly hurts the
> performance of a query.
>
> http://stackoverflow.com/q/18220761/398670
>
> CREATE OR REPLACE FUNCTION
> to_date
On 08/14/2013 08:41 AM, Craig Ringer wrote:
> Hi folks
>
> I've run into an interesting Stack Overflow post where the user shows
> that marking a particular function as IMMUTABLE significantly hurts the
> performance of a query.
Here's `perf` report data for the two.
With IMMUTABLE:
Samples: 90
Hi folks
I've run into an interesting Stack Overflow post where the user shows
that marking a particular function as IMMUTABLE significantly hurts the
performance of a query.
http://stackoverflow.com/q/18220761/398670
CREATE OR REPLACE FUNCTION
to_datestamp_immutable(time_int double precision)
On Tue, Aug 13, 2013 at 4:50 PM, Tom Lane wrote:
> Scott Marlowe writes:
>> OK I'm bumping this one last time in the hopes that someone has an
>> idea what to do to fix it.
>
>> Query plan: http://explain.depesz.com/s/kJ54
>
>> This query takes 180 seconds. It loops 17391 times across the lower
>
Scott Marlowe writes:
> OK I'm bumping this one last time in the hopes that someone has an
> idea what to do to fix it.
> Query plan: http://explain.depesz.com/s/kJ54
> This query takes 180 seconds. It loops 17391 times across the lower
> index using entries from the upper index. That seems bugg
OK I'm bumping this one last time in the hopes that someone has an
idea what to do to fix it.
Query plan: http://explain.depesz.com/s/kJ54
This query takes 180 seconds. It loops 17391 times across the lower
index using entries from the upper index. That seems buggy to me.
While the exact estimate
Hello,
I'm trying to simplify a schema, where I had many ranges floating around.
My idea is to put them all in an array field and query like this:
SELECT
event.*
FROM event
JOIN participant_details
USING (participant_id)
WHERE
tsrange(event.start, event.end) && ANY (participant_details.periods
11 matches
Mail list logo
