Re: Can this query go faster???

Hi,

> -----Ursprüngliche Nachricht-----
> Von: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org] Im Auftrag
> von Joost Kraaijeveld
> Gesendet: Dienstag, 6. Dezember 2005 10:44
> An: Pgsql-Performance
> Betreff: [PERFORM] Can this query go faster???

> SELECT customers.objectid FROM prototype.customers,
> prototype.addresses WHERE customers.contactaddress =
> addresses.objectid ORDER BY zipCode asc, housenumber asc
> LIMIT 1 OFFSET 283745
>
> Explain:
>
> Limit  (cost=90956.71..90956.71 rows=1 width=55)
>   ->  Sort  (cost=90247.34..91169.63 rows=368915 width=55)
>         Sort Key: addresses.zipcode, addresses.housenumber
>         ->  Hash Join  (cost=14598.44..56135.75 rows=368915 width=55)
>               Hash Cond: ("outer".contactaddress = "inner".objectid)
>               ->  Seq Scan on customers  (cost=0.00..31392.15
> rows=368915 width=80)
>               ->  Hash  (cost=13675.15..13675.15 rows=369315 width=55)
>                     ->  Seq Scan on addresses  (cost=0.00..13675.15
> rows=369315 width=55)
>
> The customers table has an index on contactaddress and objectid.
> The addresses table has an index on zipcode+housenumber and objectid.

The planner chooses sequential scans on customers.contactaddress and addresses.objectid instead of using the indices.
Inorder to determine whether this is a sane decision, you should run EXPLAIN ANALYZE on this query, once with SET
ENABLE_SEQSCAN= on; and once with SET ENABLE_SEQSCAN = off;. If the query is significantly faster with SEQSCAN off,
thensomething is amiss - either you haven't run analyze often enough so the stats are out of date or you have
random_page_costset too high (look for the setting in postgresql.conf) - these two are the "usual suspects". 

Kind regards

   Markus