X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id 3482B9DCC83
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue,  6 Dec 2005 05:54:00 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 77107-01
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue,  6 Dec 2005 05:54:00 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from mail3.ecircle.de (unknown [195.140.186.206])
	by postgresql.org (Postfix) with ESMTP id E4B6D9DCAEE
	for <pgsql-performance@postgresql.org>;
	Tue,  6 Dec 2005 05:53:56 -0400 (AST)
Received: from deimos.muc.ecircle.de (deimos.muc.ecircle.de [192.168.1.4])
	by mail3.ecircle.de (READY) with ESMTP id 091E411C49D;
	Tue,  6 Dec 2005 10:53:56 +0100 (CET)
Received: from [192.168.1.110] ([192.168.1.110]) by deimos.muc.ecircle.de with
	Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Dec 2005 10:52:57 +0100
Subject: Re: Can this query go faster???
From: Csaba Nagy <nagy@ecircle-ag.com>
To: Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>
Cc: Pgsql-Performance <pgsql-performance@postgresql.org>
In-Reply-To: <1133862229.8837.61.camel@Panoramix>
References: <1133862229.8837.61.camel@Panoramix>
Content-Type: text/plain
Message-Id: <1133862777.4779.185.camel@coppola.muc.ecircle.de>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Tue, 06 Dec 2005 10:52:57 +0100
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Dec 2005 09:52:57.0583 (UTC)
	FILETIME=[D61017F0:01C5FA4A]
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0 required=5 tests=[none]
X-Spam-Score: 0
X-Spam-Level: 
X-Archive-Number: 200512/152
X-Sequence-Number: 15973

Joost,

Why do you use an offset here ? I guess you're traversing the table
somehow, in this case it would be better to remember the last zipcode +
housenumber and put an additional condition to get the next bigger than
the last one you've got... that would go for the index on
zipcode+housenumber and be very fast. The big offset forces postgres to
traverse that many entries until it's able to pick the one row for the
result...

On Tue, 2005-12-06 at 10:43, Joost Kraaijeveld wrote:
> Hi,
> 
> Is it possible to get this query run faster than it does now, by adding
> indexes, changing the query?
> 
> 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.
> 
> TIA
> 
> --
> Groeten,
> 
> Joost Kraaijeveld
> Askesis B.V.
> Molukkenstraat 14
> 6524NB Nijmegen
> tel: 024-3888063 / 06-51855277
> fax: 024-3608416
> e-mail: J.Kraaijeveld@Askesis.nl
> web: www.askesis.nl
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org