pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: K C Lau <kclau60@netvigator.com>
To: PFC <lists@boutiquenumerique.com>
To: pgsql-performance@postgresql.org
Subject: Re: SELECT DISTINCT Performance Issue
Date: Mon, 06 Jun 2005 22:54:44 +0800
Message-ID: <6.2.1.2.0.20050606224010.05df3578@localhost> (raw)
In-Reply-To: <op.srx5mdsmth1vuj@localhost>
References: <6.2.1.2.0.20050602190756.05ab2c70@localhost>
	<op.srx5mdsmth1vuj@localhost>

At 19:45 05/06/06, PFC wrote:


>>Previously, we have also tried to use LIMIT 1 instead of DISTINCT, but
>>the performance was no better:
>>select PlayerID,AtDate from Player where PlayerID='22220' order by
>>PlayerID desc, AtDate desc LIMIT 1
>
>         The DISTINCT query will pull out all the rows and keep only one, 
> so the
>one with LIMIT should be faster. Can you post explain analyze of the LIMIT
>query ?

Actually the problem with LIMIT 1 query is when we use views with the LIMIT 
1 construct. The direct SQL is ok:

esdt=> explain analyze select PlayerID,AtDate from Player where 
PlayerID='22220'
  order by PlayerID desc, AtDate desc LIMIT 1;

  Limit  (cost=0.00..1.37 rows=1 width=23) (actual time=0.000..0.000 rows=1 
loops
=1)
    ->  Index Scan Backward using pk_player on player  (cost=0.00..16074.23 
rows=
11770 width=23) (actual time=0.000..0.000 rows=1 loops=1)
          Index Cond: ((playerid)::text = '22220'::text)
  Total runtime: 0.000 ms

esdt=> create or replace view VCurPlayer3 as select * from Player a
where AtDate = (select b.AtDate from Player b where a.PlayerID = b.PlayerID
order by b.PlayerID desc, b.AtDate desc LIMIT 1);

esdt=> explain analyze select PlayerID,AtDate,version from VCurPlayer3 
where Pla
yerID='22220';
  Index Scan using pk_player on player a  (cost=0.00..33072.78 rows=59 
width=27)
(actual time=235.000..235.000 rows=1 loops=1)
    Index Cond: ((playerid)::text = '22220'::text)
    Filter: ((atdate)::text = ((subplan))::text)
    SubPlan
      ->  Limit  (cost=0.00..1.44 rows=1 width=23) (actual 
time=0.117..0.117 rows
=1 loops=1743)
            ->  Index Scan Backward using pk_player on player 
b  (cost=0.00..1402
3.67 rows=9727 width=23) (actual time=0.108..0.108 rows=1 loops=1743)
                  Index Cond: (($0)::text = (playerid)::text)
  Total runtime: 235.000 ms

The problem appears to be in the loops=1743 scanning all 1743 data records 
for that player.

Regards, KC.





view thread (6+ messages)  latest in thread

Message-ID: <6.2.1.2.0.20050606224010.05df3578@localhost>
Permalink:  ../6.2.1.2.0.20050606224010.05df3578@localhost/
Also on:    postgresql.org/message-id/6.2.1.2.0.20050606224010.05df3578@localhost

 · 

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: kclau60@netvigator.com, lists@boutiquenumerique.com
  Subject: Re: SELECT DISTINCT Performance Issue
  In-Reply-To: <6.2.1.2.0.20050606224010.05df3578@localhost>

* 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