Re: Simple machine-killing query! - Mailing list pgsql-performance

From Tom Lane
Subject Re: Simple machine-killing query!
Date
Msg-id 16017.1098373308@sss.pgh.pa.us
Whole thread Raw
In response to Simple machine-killing query!  (Victor Ciurus <vikcious@gmail.com>)
Responses Re: Simple machine-killing query!
List pgsql-performance
Victor Ciurus <vikcious@gmail.com> writes:
> What I am requested to do is to keep all records from 'BIGMA' that do
> not apear in 'DIRTY'
> So far I have tried solving this by going for:

> [explain] select * from BIGMA where string not in (select * from DIRTY);
>                                QUERY PLAN
> ------------------------------------------------------------------------
>  Seq Scan on bigma  (cost=0.00..24582291.25 rows=500 width=145)
>    Filter: (NOT (subplan))
>    SubPlan
>      ->  Seq Scan on dirty  (cost=0.00..42904.63 rows=2503963 width=82)
> (4 rows)

If you are using PG 7.4, you can get reasonable performance out of this
approach, but you need to jack sort_mem up to the point where the whole
DIRTY table will fit into sort_mem (so that you get a hashed-subplan
plan and not a plain subplan).  If you find yourself setting sort_mem to
more than say half of your machine's available RAM, you should probably
forget that idea.

> [explain] select * from bigma,dirty where bigma.email!=dirty.email;

This of course does not give the right answer at all.

A trick that people sometimes use is an outer join:

select * from bigma left join dirty on (bigma.email=dirty.email)
where dirty.email is null;

Understanding why this works is left as an exercise for the reader
... but it does work, and pretty well too.  If you're using pre-7.4
PG then this is about the only effective solution AFAIR.

            regards, tom lane

pgsql-performance by date:

Previous
From: Aaron Werman
Date:
Subject: Re: Simple machine-killing query!
Next
From: "Steinar H. Gunderson"
Date:
Subject: Re: Anything to be gained from a 'Postgres Filesystem'?