Re: Performance issues

You can set it for the db user or use stored proc.

Best regards, Vitalii Tymchyshyn

Ср, 18 бер. 2015 14:48 Vivekanand Joshi <vjoshi(at)zetainteractive(dot)com> пише:

> 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(at)comcast(dot)net]
> Sent: Thursday, March 19, 2015 12:06 AM
> To: vjoshi(at)zetainteractive(dot)com
> Cc: Tomas Vondra; pgsql-performance(at)postgresql(dot)org
> Subject: Re: [PERFORM] Performance issues
>
> Vivekanand Joshi <vjoshi(at)zetainteractive(dot)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(at)postgresql(dot)org
> > [mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of Tomas
> > Vondra
> > Sent: Tuesday, March 17, 2015 9:00 PM
> > To: pgsql-performance(at)postgresql(dot)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(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-performance
>
> --
> Jerry Sievers
> Postgres DBA/Development Consulting
> e: postgres(dot)consulting(at)comcast(dot)net
> p: 312.241.7800
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>