pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Heikki Linnakangas <heikki@enterprisedb.com>
To: cluster <skrald@amossen.dk>
Cc: pgsql-performance@postgresql.org
Subject: Re: Two fast queries get slow when combined
Date: Tue, 30 Oct 2007 21:46:45 +0000
Message-ID: <4727A645.2040302@enterprisedb.com> (raw)
In-Reply-To: <fg85ae$1740$1@news.hub.org>
References: <fg85ae$1740$1@news.hub.org>

cluster wrote:
>   SELECT keyId, sortNum, count(1)
>   FROM stats s, items i
>   WHERE s.keyId = i.keyId AND i.sortNum > 123
>   GROUP BY i.keyId, i.sortNum
>   ORDER BY i.sortNum
>   LIMIT 50
> 
> Limit  (cost=3281.72..3281.84 rows=50 width=16) (actual 
> time=435.838..436.043 rows=50 loops=1)
>    InitPlan
>      ->  Limit  (cost=0.00..0.01 rows=1 width=0) (actual 
> time=0.016..0.021 rows=1 loops=1)
>            ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual 
> time=0.012..0.013 rows=1 loops=1)
>    ->  Sort  (cost=3281.71..3289.97 rows=3304 width=16) (actual 
> time=435.833..435.897 rows=50 loops=1)
>          Sort Key: i.sortNum
>          ->  Hash Join  (cost=2745.80..3088.59 rows=3304 width=16) 
> (actual time=364.247..413.164 rows=8490 loops=1)
>                Hash Cond: (s.keyId = i.keyId)
>                ->  HashAggregate  (cost=2270.53..2394.43 rows=9912 
> width=8) (actual time=337.869..356.533 rows=9911 loops=1)
>                      ->  Seq Scan on items  (cost=0.00..1527.16 
> rows=99116 width=8) (actual time=0.016..148.118 rows=99116 loops=1)
>                ->  Hash  (cost=408.47..408.47 rows=5344 width=12) 
> (actual time=26.342..26.342 rows=4491 loops=1)
>                      ->  Bitmap Heap Scan on items i 
> (cost=121.67..408.47 rows=5344 width=12) (actual time=5.007..16.898 
> rows=4491 loops=1)
>                            Recheck Cond: (sortNum >= $0)
>                            ->  Bitmap Index Scan on items_sortNum 
> (cost=0.00..120.33 rows=5344 width=0) (actual time=4.273..4.273 
> rows=13375 loops=1)
>                                  Index Cond: (sortNum >= $0)
> Total runtime: 436.421 ms
> (16 rows)

There's something odd about that plan. It's doing both a seq scan and a 
bitmap scan on "items", but I can't see stats table being mentioned 
anywhere. Looking at the row count, I believe that seq scan is actually 
on the stats table, not items like it says above. Is that really a 
verbatim copy of the output you got?

Which version of Postgres is this?

You could try rewriting the query like this:

SELECT keyId, sortNum,
   (SELECT count(*) FROM stats s WHERE s.keyId = i.keyId) AS stats_cnt
FROM items i
WHERE i.sortNum > 123
ORDER BY sortNum
LIMIT 50

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com



view thread (5+ messages)  latest in thread

Message-ID: <4727A645.2040302@enterprisedb.com>
Permalink:  ../4727A645.2040302@enterprisedb.com/
Also on:    postgresql.org/message-id/4727A645.2040302@enterprisedb.com

 · 

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: heikki@enterprisedb.com, skrald@amossen.dk
  Subject: Re: Two fast queries get slow when combined
  In-Reply-To: <4727A645.2040302@enterprisedb.com>

* 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