pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Chris Bowlby <excalibur@accesswave.ca>
To: pgsql-performance@postgresql.org
Subject: Re: significant slow down with various LIMIT
Date: Tue, 13 Apr 2010 14:59:55 -0300
Message-ID: <4BC4B11B.6090106@accesswave.ca> (raw)
In-Reply-To: <4BC4627202000025000307E5@gw.wicourts.gov>
References: <4BC2C7140200002500030705@gw.wicourts.gov>
	<f4ecdf51-a74f-45f7-9b6d-87244787ca6b@x3g2000yqd.googlegroups.com>
	<4BC34A340200002500030759@gw.wicourts.gov>
	<e1a8a6b8-d5c3-4bf1-8df7-007e5950b698@q23g2000yqd.googlegroups.com>
	<4BC4627202000025000307E5@gw.wicourts.gov>

I'm also wondering if a re-clustering of the table would work based on
the index that's used.

such that:

CLUSTER core_object USING plugins_plugin_addr_oid_id;

and see if that makes any change in the differences that your seeing.

On 04/13/2010 02:24 PM, Kevin Grittner wrote:
> norn <andrey.perliev@gmail.com> wrote:
>  
>   
>> I am wondering why there are so big gap between two limits and how
>> to avoid this...
>>     
>  
> I think we've already established that it is because of the
> percentage of the table which must be scanned to get to the desired
> number of rows.  The problem is exacerbated by the fact that it's a
> "backward" scan on the index, which is slower than a forward scan --
> mainly because disks spin in one direction, and the spacing of the
> sectors is optimized for forward scans.
>  
> There are a couple things to try which will give a more complete
> picture of what might work to make the run time more predictable. 
> Please try these, and run EXPLAIN ANALYZE of your problem query each
> way.
>  
> (1) Try it without the ORDER BY clause and the LIMIT.
>  
> (2) Temporarily take that top index out of consideration.  (Don't
> worry, it'll come back when you issue the ROLLBACK -- just don't
> forget the BEGIN statement.)
>   
> BEGIN;
> DROP INDEX plugins_plugin_addr_oid_id;
> explain analyze <your query>
> ROLLBACK;
>  
> (3) Try it like this (untested, so you may need to fix it up):
>  
> explain analyze
> SELECT core_object.id
>   from (SELECT id, city_id FROM "plugins_guide_address")
>        "plugins_guide_address"
>   JOIN "plugins_plugin_addr"
>     ON ("plugins_plugin_addr"."address_id"
>        = "plugins_guide_address"."id")
>   JOIN "core_object"
>     ON ("core_object"."id" = "plugins_plugin_addr"."oid_id")
>   WHERE "plugins_guide_address"."city_id" = 4535
>   ORDER BY "core_object"."id" DESC
>   LIMIT 4 -- or whatever it normally takes to cause the problem
> ;
>  
> -Kevin
>
>   




view thread (19+ messages)  latest in thread

Message-ID: <4BC4B11B.6090106@accesswave.ca>
Permalink:  ../4BC4B11B.6090106@accesswave.ca/
Also on:    postgresql.org/message-id/4BC4B11B.6090106@accesswave.ca

 · 

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: excalibur@accesswave.ca
  Subject: Re: significant slow down with various LIMIT
  In-Reply-To: <4BC4B11B.6090106@accesswave.ca>

* 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