You can set it for the db user or use stored proc. Best regards, Vitalii Tymchyshyn
Ср, 18 бер. 2015 14:48 Vivekanand Joshi <vjo...@zetainteractive.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:gsiever...@comcast.net] > Sent: Thursday, March 19, 2015 12:06 AM > To: vjo...@zetainteractive.com > Cc: Tomas Vondra; pgsql-performance@postgresql.org > Subject: Re: [PERFORM] Performance issues > > Vivekanand Joshi <vjo...@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-ow...@postgresql.org > > [mailto:pgsql-performance-ow...@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.consult...@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 >
