pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Felipe Santos <felipepts@gmail.com>
To: vjoshi@zetainteractive.com
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Performance issues
Date: Wed, 18 Mar 2015 14:51:06 -0300
Message-ID: <CAPYcRiXaDMLw4YWCFcEpTLg7DT1NJVGHfUm06aAb135xZwO2Zw@mail.gmail.com> (raw)
In-Reply-To: <9650933705b1a197888f77acbef26728@mail.gmail.com>
References: <84a6fe4be04c3ef0a714851977860ac8@mail.gmail.com>
	<CACKkDGETLNUON-bLM0gCo_r-+ts3Q29aQwmargv1Usi=PgQvVg@mail.gmail.com>
	<CANwLwatODrcwDgO+JXG-L=jJJQTucvUrur01E-y_tE_PT8i7kQ@mail.gmail.com>
	<55034A48.4040409@2ndquadrant.com>
	<CANwLwavsL-+SDRB7VKxQ_OJq-T=MVQV6T6qH5Aug9PaSWt2C0w@mail.gmail.com>
	<CACKkDGHOnb2efYvLj557E5pSuzS+Wmu9dqG3Z=b_dbYhpi7muQ@mail.gmail.com>
	<CAOR=d=2L86fB+HWX8h078tYsd7LVKKFPQb=jfd8YNRU1Fc7mUA@mail.gmail.com>
	<849e75d9463938372dd4c516f5c5d89c@mail.gmail.com>
	<55037CEA.5050906@2ndquadrant.com>
	<55073272.20209@BlueTreble.com>
	<55074424.9050506@2ndquadrant.com>
	<55076FFB.9090105@BlueTreble.com>
	<acf5780f0e3c7d42d5f6499830378008@mail.gmail.com>
	<55083236.8070900@2ndquadrant.com>
	<me9d4u$9b5$1@ger.gmane.org>
	<55083D74.4000601@2ndquadrant.com>
	<me9guu$cvp$1@ger.gmane.org>
	<55084890.6000907@2ndquadrant.com>
	<9650933705b1a197888f77acbef26728@mail.gmail.com>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

2015-03-18 14:31 GMT-03:00 Vivekanand Joshi <vjoshi@zetainteractive.com>:

> 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.
>
>
>
>
> 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
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>




"But this is not a production-suitable setting. So what do you think how to
get a work around this?"

What about creating a read-only replica and apply this setting there?

view thread (59+ messages)  latest in thread

Message-ID: <CAPYcRiXaDMLw4YWCFcEpTLg7DT1NJVGHfUm06aAb135xZwO2Zw@mail.gmail.com>
Permalink:  ../CAPYcRiXaDMLw4YWCFcEpTLg7DT1NJVGHfUm06aAb135xZwO2Zw@mail.gmail.com/
Also on:    postgresql.org/message-id/CAPYcRiXaDMLw4YWCFcEpTLg7DT1NJVGHfUm06aAb135xZwO2Zw@mail.gmail.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: felipepts@gmail.com, vjoshi@zetainteractive.com, tomas.vondra@2ndquadrant.com
  Subject: Re: Performance issues
  In-Reply-To: <CAPYcRiXaDMLw4YWCFcEpTLg7DT1NJVGHfUm06aAb135xZwO2Zw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox