Reply-To: <vjoshi@zetainteractive.com>
From: Vivekanand Joshi <vjoshi@zetainteractive.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>
 c5231342781287ff8cbc9ac1f20ff036@mail.gmail.com
 <61a7 a27428e588411e8ac1817043205c@mail.gmail.com> <550813CD.7040605@2ndqu
 adrant.com> d6a86358c5e8d7ffe923ff307c3e8c7e@mail.gmail.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@2ndqu adrant.com>
In-Reply-To: <55084890.6000907@2ndquadrant.com>
MIME-Version: 1.0
thread-index: 
 AQGXPdRf3VxuG24kJ8WwflsQcHnAgQHf4jwuAfE4xDgBl0RAUAJmr3goASgXauMC6fPnxQEuEGdFAhncSY0BmjXsSgGh9PN2AN4iKXMA5v7gwQERqjvMAf4nDaMBwGLzhAGT0FuxAeJl4uACMa83JAIZZZVOnI7nX1A=
Date: Wed, 18 Mar 2015 23:01:15 +0530
Message-ID: <9650933705b1a197888f77acbef26728@mail.gmail.com>
Subject: Re: Performance issues
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
 pgsql-performance@postgresql.org
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

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?


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