Re: Oracle v. Postgres 9.0 query performance

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

In response to

Responses

Browse pgsql-performance by date

  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