Re: Oracle v. Postgres 9.0 query performance - Mailing list pgsql-performance

From Stephen Frost
Subject Re: Oracle v. Postgres 9.0 query performance
Date
Msg-id 20110608155159.GA18128@tamriel.snowman.net
Whole thread Raw
In response to Re: Oracle v. Postgres 9.0 query performance  (Tony Capobianco <tcapobianco@prospectiv.com>)
Responses Re: Oracle v. Postgres 9.0 query performance  (Tony Capobianco <tcapobianco@prospectiv.com>)
Re: Oracle v. Postgres 9.0 query performance  (Tatsuo Ishii <ishii@postgresql.org>)
List pgsql-performance
* Tony Capobianco (tcapobianco@prospectiv.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

Attachment

pgsql-performance by date:

Previous
From: Tony Capobianco
Date:
Subject: Re: Oracle v. Postgres 9.0 query performance
Next
From: Vitalii Tymchyshyn
Date:
Subject: Re: Oracle v. Postgres 9.0 query performance