Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1V74x6-00026a-8D for pgsql-performance@arkaria.postgresql.org; Wed, 07 Aug 2013 14:43:04 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1V74x5-0000XG-OT for pgsql-performance@arkaria.postgresql.org; Wed, 07 Aug 2013 14:43:03 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1V74x4-0000XA-OW for pgsql-performance@postgresql.org; Wed, 07 Aug 2013 14:43:02 +0000 Received: from gmmr2.centrum.cz ([2a00:da80:1:502::2]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1V74ww-0004jZ-Tj for pgsql-performance@postgresql.org; Wed, 07 Aug 2013 14:43:01 +0000 Received: from mail1003.cent (unknown [10.32.3.102]) by gmmr2.centrum.cz (Postfix) with ESMTP id A4F8F60000D8; Wed, 7 Aug 2013 16:42:50 +0200 (CEST) Received: by mail1003.cent (Postfix, from userid 33) id 9BFDE200456D7; Wed, 7 Aug 2013 16:42:50 +0200 (CEST) To: =?utf-8?q?Igor_Neyman?= , =?utf-8?q?Pavel_Stehule?= Subject: =?utf-8?q?RE=3A_=5BPERFORM=5D_Re=3A_=5BPERFORM=5D_Sub=2Doptimal_plan_for_a_paginated_query_on_a_view_with_another_view_inside_of_it=2E?= Received: from 195.168.8.115 (X-Forwarded-For: 195.168.8.115) by mail1003.centrum.cz (centrum.cz multimail) with HTTP Date: Wed, 07 Aug 2013 16:42:50 +0200 From: Cc: =?utf-8?q?pgsql=2Dperformance=40postgresql=2Eorg?= References: <20130802154316.59167BB5@centrum.sk>, , <20130807144239.654353D3@centrum.sk> In-Reply-To: X-Mailer: Centrum Email 5.3 X-Priority: 3 X-Original-From: slapo@centrum.sk MIME-Version: 1.0 Message-Id: <20130807164250.26C21834@centrum.sk> X-Maser: Georgo X-Pg-Spam-Score: -1.9 (-) Content-Type: multipart/alternative; boundary="_d32c_-------3e41c39d2dd253fceb7e38aac2b283ad" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org This is a multi-part message in MIME format. --_ca29_-------7c296d4c426ea5811d0f225a319db5d2 Content-Type: multipart/alternative; boundary="_d32c_-------3e41c39d2dd253fceb7e38aac2b283ad" --_d32c_-------3e41c39d2dd253fceb7e38aac2b283ad Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit You're right, it does... but it's quite odd, because I re-ran the explain-analyze statement and got the same results. Still, the query now runs for about a second as mentioned before, so it's almost like something's missing from the explain, but I'm certain I copied it all.   I did this via pgadmin, but that shouldn't matter, should it?   Thank you,   Peter Slapansky ______________________________________________________________ > Od: Igor Neyman > Komu: "slapo@centrum.sk" , Pavel Stehule > Dátum: 07.08.2013 15:47 > Predmet: RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. > > CC: "pgsql-performance@postgresql.org" Your last explain analyze (with 3 settings set to 32)  shows query duration 10ms, not 1sec. Am I wrong?  Regards, Igor Neyman   ______________________________________________________________ From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of slapo@centrum.sk Sent: Wednesday, August 07, 2013 8:43 AM To: Pavel Stehule Cc: pgsql-performance@postgresql.org Subject: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Good day,   I have included a link to the result of EXPLAIN ANALYZE. It's this one: https://app.box.com/s/u8nk6qvkjs4ae7l7dh4h   Here's a link to Depesz's explain (if links to the site are okay): http://explain.depesz.com/s/gCk   I have just tried setting geqo_threshold, join_collapse_limit and from_collapse_limit to 16, but it yielded no improvement. Changing those three parameters to 32 did speed up the query from about 3.3 seconds to about a second (give or take 50 ms), which is a pretty good improvement, but not quite there, as I'm looking to bring it down to about 300 ms if possible. Changing those three settings to 48 yielded no improvements over 32. Is there possibly something something else to tweak there?   Here's EXPLAIN ANALYZE output when the three settings have been set to 32: http://explain.depesz.com/s/cj2   Thank you.   Peter Slapansky --_d32c_-------3e41c39d2dd253fceb7e38aac2b283ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

You're right, it does... but it's quite odd, because I re-ran the explain-analyze statement and got the same results.

Still, the query now runs for about a second as mentioned before, so it's almost like something's missing from the explain, but I'm certain I copied it all.

 

I did this via pgadmin, but that shouldn't matter, should it?

 

Thank you,

 

Peter Slapansky

______________________________________________________________
> Od: Igor Neyman <ineyman@perceptron.com>
> Komu: "slapo@centrum.sk" <slapo@centrum.sk>, Pavel Stehule <pavel.stehule@gmail.com>
> Dátum: 07.08.2013 15:47
> Predmet: RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
>

> CC: "pgsql-performance@postgresql.org"

Your last explain analyze (with 3 settings set to 32)  shows query duration 10ms, not 1sec.
Am I wrong? 

Regards,
Igor Neyman

 

______________________________________________________________
From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of slapo@centrum.sk
Sent: Wednesday, August 07, 2013 8:43 AM
To: Pavel Stehule
Cc: pgsql-performance@postgresql.org
Subject: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.

Good day,
 
I have included a link to the result of EXPLAIN ANALYZE. It's this one:
https://app.box.com/s/u8nk6qvkjs4ae7l7dh4h
 
Here's a link to Depesz's explain (if links to the site are okay):
http://explain.depesz.com/s/gCk
 
I have just tried setting geqo_threshold, join_collapse_limit and from_collapse_limit to 16, but it yielded no improvement.
Changing those three parameters to 32 did speed up the query from about 3.3 seconds to about a second (give or take 50 ms), which is a pretty good improvement, but not quite there, as I'm looking to bring it down to about 300 ms if possible. Changing those three settings to 48 yielded no improvements over 32.
Is there possibly something something else to tweak there?
 
Here's EXPLAIN ANALYZE output when the three settings have been set to 32:
http://explain.depesz.com/s/cj2
 
Thank you.
 
Peter Slapansky

--_d32c_-------3e41c39d2dd253fceb7e38aac2b283ad-- --_ca29_-------7c296d4c426ea5811d0f225a319db5d2--