Re: New dot releases

From: Devrim GUNDUZ <devrim(at)gunduz(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Fuhr <mike(at)fuhr(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: New dot releases
Date: 2005-09-19 13:01:42
Message-ID: Pine.LNX.4.63.0509191600260.8539@mail.kivi.com.tr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hi,

On Fri, 16 Sep 2005, Michael Fuhr wrote:

> On Fri, Sep 16, 2005 at 09:28:39AM -0600, Michael Fuhr wrote:
>> FWIW, I have a Solaris 9/sparc box with gcc 3.4.2 (same setup as
>> gerbil) and have no problems with REL7_2_STABLE through HEAD. I'll
>> test REL8_0_STABLE with gerbil's configure options when I get a
>> chance.
>
> I just built REL8_0_STABLE with the following configure options
> (same as gerbil):
>
> ./configure --enable-cassert --enable-debug --enable-nls \
> --enable-integer-datetimes --with-perl --with-python \
> --with-openssl --with-pgport=5682
>
> gmake check returned the following:
>
> ======================
> All 96 tests passed.
> ======================

So no need to hold the new dot releases? :)

I want to work on new RPM sets and don't want to apply countless
patches... :)

Regards,
--
Devrim GUNDUZ
Kivi Bilişim Teknolojileri - http://www.kivi.com.tr
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
>From pgsql-hackers-owner(at)postgresql(dot)org Mon Sep 19 11:27:58 2005
X-Original-To: pgsql-hackers-postgresql(dot)org(at)localhost(dot)postgresql(dot)org
Received: from localhost (av.hub.org [200.46.204.144])
by svr1.postgresql.org (Postfix) with ESMTP id 0556DD9369
for <pgsql-hackers-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>; Mon, 19 Sep 2005 11:27:57 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
with ESMTP id 84481-05
for <pgsql-hackers-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>;
Mon, 19 Sep 2005 14:27:44 +0000 (GMT)
Received: from mx03.kabsi.at (mx03.kabsi.at [195.202.128.130])
by svr1.postgresql.org (Postfix) with ESMTP id E2D85D92FB
for <pgsql-hackers(at)postgresql(dot)org>; Mon, 19 Sep 2005 11:27:44 -0300 (ADT)
Received: from [192.168.0.5] (h062040243020.plc.cm.kabsi.at [62.40.243.20])
by mx03.kabsi.at (8.13.3/8.13.3) with ESMTP id j8JERlm6020025
for <pgsql-hackers(at)postgresql(dot)org>; Mon, 19 Sep 2005 16:27:47 +0200
Message-ID: <432ECAE2(dot)7070805(at)cybertec(dot)at>
Date: Mon, 19 Sep 2005 16:27:46 +0200
From: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <postgres(at)cybertec(dot)at>
User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pgsql-hackers(at)postgresql(dot)org
Subject: DISTINCT vs. GROUP BY
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.01 required=5 tests=[AWL=0.010]
X-Spam-Level:
X-Archive-Number: 200509/808
X-Sequence-Number: 73205

I was wondering whether it is possible to teach the planner to handle
DISTINCT in a more efficient way:

em=# explain select distinct lastname from import.testtest;
QUERY PLAN
--------------------------------------------------------------------------------
Unique (cost=2647377.45..2709467.70 rows=1 width=7)
-> Sort (cost=2647377.45..2678422.58 rows=12418051 width=7)
Sort Key: lastname
-> Seq Scan on testtest (cost=0.00..370082.51 rows=12418051
width=7)
(4 Zeilen)

Isn't it possible to perform the same operation using a HashAggregate?
We have seen that a GROUP BY workaround is usually a lot faster than
sort->unique - at least when work_mem is large enough.

best regards,

hans

--
Cybertec Geschwinde & Schönig GmbH
Schöngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2005-09-19 14:52:45 Re: DISTINCT vs. GROUP BY
Previous Message Jonah H. Harris 2005-09-19 11:56:43 Re: 64-bit API for large objects