/m: 
Received: from unknown (HELO ?10.2.2.158?) (kouber@securax.org@10.2.2.158)
	by cocaine with ESMTPA; 23 Feb 2009 12:26:07 -0000
Message-ID: <49A295F0.5010405@saparev.com>
Date: Mon, 23 Feb 2009 14:26:24 +0200
From: Kouber Saparev <kouber@saparev.com>
Reply-To: kouber@saparev.com
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: LIMIT confuses the planner
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200902/262
X-Sequence-Number: 32843

Hello,

I'm experiencing a strange issue. I have a table with around 11 million 
records (11471762 to be exact), storing login attempts to a web site. 
Thanks to the index I have created on username, looking into that table 
by username is very fast:


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
(6 rows)


As you can see, there are only 2 records for that particular username.

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;
 
   QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------
  Limit  (cost=0.00..770.45 rows=20 width=38) (actual 
time=0.064..3797.660 rows=2 loops=1)
    ->  Index Scan Backward using login_attempt_pkey on login_attempt 
(cost=0.00..304866.46 rows=7914 width=38) (actual time=0.062..3797.657 
rows=2 loops=1)
          Filter: ((username)::text = 'kouber'::text)
  Total runtime: 3797.691 ms
(4 rows)


Now, recently I have altered some of the default parameters in order to 
get as much as possible out of the hardware - 12 GB of RAM, 8 
processors. So, I guess I have done something wrong, thus the planner is 
taking that wrong decision. Here's what I have changed in 
postgresql.conf (from the default one):

max_connections = 200
shared_buffers = 256MB
work_mem = 64MB
maintenance_work_mem = 128MB
max_stack_depth = 6MB
max_fsm_pages = 100000
synchronous_commit = off
wal_buffers = 1MB
commit_delay = 100
commit_siblings = 5
checkpoint_segments = 10
checkpoint_timeout = 10min
random_page_cost = 0.1
effective_cache_size = 2048MB

Any idea what's wrong here?

Regards,
-- 
Kouber Saparev
http://kouber.saparev.com