From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: queries with lots of UNIONed relations |
Date: | 2011-01-14 00:10:27 |
Message-ID: | 20541.1294963827@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> writes:
> On Thu, Jan 13, 2011 at 5:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If you have enough memory to de-dup them individually, you surely have
>> enough to de-dup all at once.
> If everything were available up-front, sure.
> However, and please correct me if I'm wrong, but doesn't postgresql
> work in a fairly linear fashion, moving from table to table performing
> a series of operations on each?
Doing a single sort+uniq works like that. But the alternate plan you
are proposing we should consider involves building all the lower
hashtables, and then reading from them to fill the upper hashtable.
Max memory consumption *is* worst case here. Remember HashAggregate
is incapable of swapping to disk (and if it did, you wouldn't be nearly
as pleased with its performance).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mladen Gogala | 2011-01-14 03:19:19 | Re: queries with lots of UNIONed relations |
Previous Message | Jon Nelson | 2011-01-13 23:14:04 | Re: queries with lots of UNIONed relations |