From: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: queries with lots of UNIONed relations |
Date: | 2011-01-13 20:12:43 |
Message-ID: | AANLkTimx00ADoFDbOyFixLOSy4ypKjhQrHnTzanepbJD@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Jan 13, 2011 at 2:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> writes:
>> Your comment regarding "each individual de-duplication looked like it
>> would fit in work_mem" doesn't really make sense, exactly. Maybe I'm
>> misunderstanding you.
>
> Yeah. What I was suggesting was to NOT add the DISTINCT's, but instead
> raise work_mem high enough so you get just one HashAggregation step at
> the top level. (Although I think this only works in 8.4 and up.)
> That should be faster than two levels of de-duplication.
Gave it a try -- performance either way doesn't seem to change -
although the final set that has to undergo de-duplication is rather
larger (WITHOUT DISTINCT) so I still run the risk of not getting Hash
Aggregation.
Since having the DISTINCT doesn't seem to hurt, and it avoids
(potential) significant pain, I'll keep it.
I still think that having UNION do de-duplication of each contributory
relation is a beneficial thing to consider -- especially if postgresql
thinks the uniqueness is not very high.
Thanks!
--
Jon
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-13 21:44:30 | Re: queries with lots of UNIONed relations |
Previous Message | Tom Lane | 2011-01-13 20:05:44 | Re: queries with lots of UNIONed relations |