Re: queries with lots of UNIONed relations

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

In response to

Responses

Browse pgsql-performance by date

  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