Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 48B34633857 for ; Tue, 9 Feb 2010 21:44:05 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 19284-01 for ; Wed, 10 Feb 2010 01:43:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ulysses.lattica.com (lattica.com [204.14.19.114]) by mail.postgresql.org (Postfix) with ESMTP id 8F13E633170 for ; Tue, 9 Feb 2010 21:43:54 -0400 (AST) Received: from localhost (ulysses.lattica.com [127.0.0.1]) by ulysses.lattica.com (Postfix) with ESMTP id 0FF3773852D; Tue, 9 Feb 2010 20:43:53 -0500 (EST) X-Virus-Scanned: amavisd-new at lattica.com Received: from ulysses.lattica.com ([127.0.0.1]) by localhost (ulysses.lattica.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+XObs++IZF8; Tue, 9 Feb 2010 20:43:48 -0500 (EST) Received: from [192.168.3.11] (CPE00222d5a2ad0-CM00222d5a2acd.cpe.net.cable.rogers.com [99.230.157.51]) by ulysses.lattica.com (Postfix) with ESMTP id DA313EA4001; Tue, 9 Feb 2010 20:43:47 -0500 (EST) Subject: Re: DISTINCT vs. GROUP BY From: Dimi Paun To: pgsql-performance Cc: Tom Lane , Mihai Popa In-Reply-To: <25105.1265755101@sss.pgh.pa.us> References: <1265751976.2513.34.camel@localhost> <25105.1265755101@sss.pgh.pa.us> Content-Type: text/plain; charset="UTF-8" Organization: Lattica, Inc. Date: Tue, 09 Feb 2010 20:43:47 -0500 Message-ID: <1265766227.2513.41.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 (2.28.2-1.fc12) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.855 tagged_above=-10 required=5 tests=AWL=0.745, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/145 X-Sequence-Number: 37566 On Tue, 2010-02-09 at 17:38 -0500, Tom Lane wrote: > The results certainly ought to be the same (although perhaps not with > the same ordering) --- if they aren't, please provide a reproducible > test case. The results are the same, this is not a problem. > As for efficiency, though, 8.1 didn't understand how to use hash > aggregation for DISTINCT. Less-obsolete versions do know how to do > that. Indeed, this seem to be the issue: tts_server_db=# EXPLAIN ANALYZE select userdata from tagrecord where clientRmaInId = 'CPC-RMA-00110' group by userdata; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------ HashAggregate (cost=253.34..253.50 rows=16 width=15) (actual time=0.094..0.094 rows=0 loops=1) -> Index Scan using idx_tagdata_clientrmainid on tagrecord (cost=0.00..252.85 rows=195 width=15) (actual time=0.091..0.091 rows=0 loops=1) Index Cond: ((clientrmainid)::text = 'CPC-RMA-00110'::text) Total runtime: 0.146 ms (4 rows) tts_server_db=# EXPLAIN ANALYZE select distinct userdata from tagrecord where clientRmaInId = 'CPC-RMA-00110'; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------------ Unique (cost=260.27..261.25 rows=16 width=15) (actual time=0.115..0.115 rows=0 loops=1) -> Sort (cost=260.27..260.76 rows=195 width=15) (actual time=0.113..0.113 rows=0 loops=1) Sort Key: userdata -> Index Scan using idx_tagdata_clientrmainid on tagrecord (cost=0.00..252.85 rows=195 width=15) (actual time=0.105..0.105 rows=0 loops=1) Index Cond: ((clientrmainid)::text = 'CPC-RMA-00110'::text) Total runtime: 0.151 ms (6 rows) For now we are stuck with 8.1, so the easiest fix for us is to use GROUP BY. Since this is fixed in later versions, I guess there's not much to see here... :) Thanks for the quick reply! -- Dimi Paun Lattica, Inc.