Message-ID: <49A2A450.20002@archonet.com>
Date: Mon, 23 Feb 2009 13:27:44 +0000
From: Richard Huxton <dev@archonet.com>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: kouber@saparev.com
CC: pgsql-performance@postgresql.org
Subject: Re: LIMIT confuses the planner
References: <49A295F0.5010405@saparev.com>
In-Reply-To: <49A295F0.5010405@saparev.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Kouber Saparev wrote:

> db=# EXPLAIN ANALYZE
> SELECT
>   *
> FROM
>   login_attempt
> WHERE
>   username='kouber'
> ORDER BY
>   login_attempt_sid DESC;
> 
> QUERY PLAN
> ------------------------------------------------------------------------------------------------------------------------------------------------------
> 
>  Sort  (cost=1415.15..1434.93 rows=7914 width=38) (actual
> time=0.103..0.104 rows=2 loops=1)
>    Sort Key: login_attempt_sid
>    Sort Method:  quicksort  Memory: 25kB
>    ->  Index Scan using login_attempt_username_idx on login_attempt
> (cost=0.00..902.71 rows=7914 width=38) (actual time=0.090..0.091 rows=2
> loops=1)
>          Index Cond: ((username)::text = 'kouber'::text)
>  Total runtime: 0.140 ms

It's expecting 7914 rows returned and is getting only 2. That is
probably the root of the problem.

> However when I add a LIMIT clause to the same query the planner no
> longer uses the right index, hence the query becomes very slow:
> 
> 
> db=# EXPLAIN ANALYZE
> SELECT
>   *
> FROM
>   login_attempt
> WHERE
>   username='kouber'
> ORDER BY
>   login_attempt_sid DESC LIMIT 20;

Since it's expecting 7914 rows for "kouber" it thinks it will find the
20 rows you want fairly quickly by just looking backward through the
login_attempt_pkey index.

Try increasing the stats on the username column.

ALTER TABLE login_attempt ALTER COLUMN username SET STATISTICS 100;
ANALYZE login_attempt;

You can try different values of statistics up to 1000, but there's no
point in setting it too high.

-- 
  Richard Huxton
  Archonet Ltd