From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tony Capobianco <tcapobianco(at)prospectiv(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Oracle v. Postgres 9.0 query performance |
Date: | 2011-06-08 15:51:59 |
Message-ID: | 20110608155159.GA18128@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
* Tony Capobianco (tcapobianco(at)prospectiv(dot)com) wrote:
> HashAggregate (cost=4391163.81..4391288.05 rows=9939 width=12)
> -> Hash Join (cost=14.78..4344767.23 rows=9279316 width=12)
> Hash Cond: (o.emailcampaignid = s.emailcampaignid)
> -> Seq Scan on openactivity o (cost=0.00..3529930.67
> rows=192540967 width=12)
> -> Hash (cost=8.79..8.79 rows=479 width=4)
> -> Seq Scan on ecr_sents s (cost=0.00..8.79 rows=479
> width=4)
>
> Yikes. Two sequential scans.
Err, isn't that more-or-less exactly what you want here? The smaller
table is going to be hashed and then you'll traverse the bigger table
and bounce each row off the hash table. Have you tried actually running
this and seeing how long it takes? The bigger table doesn't look to be
*that* big, if your i/o subsystem is decent and you've got a lot of
memory available for kernel cacheing, should be quick.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Vitalii Tymchyshyn | 2011-06-08 15:52:05 | Re: Oracle v. Postgres 9.0 query performance |
Previous Message | Tony Capobianco | 2011-06-08 15:40:34 | Re: Oracle v. Postgres 9.0 query performance |