Re: Performance issues - Mailing list pgsql-performance

The issue here is that the queries are running inside a Jasper Reports. So
we cannot set this only for a one single query.

We are accessing our reports from a web-browser, which in turn runs the
report from Application Server (Jasper). This server connects to
PostgreSQL server.

Inside a JRXML(Jasper report file) file we cannot set this parameter.

I am attaching a JRXML file for a feel.  You can open this file in
notepad. I don't think we can set server level property in this file. So
how about a workaround?

Vivek



-----Original Message-----
From: Jerry Sievers [mailto:gsievers19@comcast.net]
Sent: Thursday, March 19, 2015 12:06 AM
To: vjoshi@zetainteractive.com
Cc: Tomas Vondra; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Performance issues

Vivekanand Joshi <vjoshi@zetainteractive.com> writes:

> So, here is the first taste of success and which gives me the
> confidence that if properly worked out with a good hardware and proper
> tuning, PostgreSQL could be a good replacement.
>
> Out of the 9 reports which needs to be migrated in PostgreSQL, 3 are
> now running.
>
> Report 4 was giving an issue and I will see it tomorrow.
>
> Just to inform you guys that, the thing that helped most is setting
> enable_nestloops to false worked. Plans are now not miscalculated.
>
> But this is not a production-suitable setting. So what do you think
> how to get a work around this?

Consider just disabling that setting for 1 or a few odd queries you have
for which they are known  to plan badly.

begin;
set local enable_nestloops to false;
select ...;
commit/abort;

I'd say never make that sort of setting DB or cluster-wide.


>
>
> Regards,
> Vivek
>
> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Tomas
> Vondra
> Sent: Tuesday, March 17, 2015 9:00 PM
> To: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Performance issues
>
> On 17.3.2015 16:24, Thomas Kellerer wrote:
>> Tomas Vondra schrieb am 17.03.2015 um 15:43:
>>> On 17.3.2015 15:19, Thomas Kellerer wrote:
>>>> Tomas Vondra schrieb am 17.03.2015 um 14:55:
>>>>>  (2) using window functions, e.g. like this:
>>>>>
>>>>>      SELECT * FROM (
>>>>>        SELECT *,
>>>>>             ROW_NUMBER() OVER (PARTITION BY touchpoint_execution_id
>>>>>                                ORDER BY FROM max_creation_dt) AS rn
>>>>>        FROM s_f_touchpoint_execution_status_history
>>>>>      ) foo WHERE rn = 1
>>>>>
>>>>>      But estimating this is also rather difficult ...
>>>>
>>>>
>>>> From my experience rewriting something like the above using
>>>> DISTINCT ON is usually faster.
>>>
>>> How do you get the last record (with respect to a timestamp column)
>>> using a DISTINCT ON?
>>
>> You need to use "order by ... desc". See here:
>> http://sqlfiddle.com/#!15/d4846/2
>
> Nice, thanks!
>
>>
>> Btw: your row_number() usage wouldn't return the "latest" row either.
>> It would return the "oldest" row.
>
> Oh, right. I forgot the DESC in the window.
>
>
> --
> Tomas Vondra                http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
> --
> Sent via pgsql-performance mailing list
> (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance

--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net
p: 312.241.7800

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance