Re: Slow query needs a kick in the pants.

Do it in two stages, find the primary keys first, then do a search on on IN such
and such query, (BUT 'IN' is slow, some others can recommend a faster alternative. )

Just an idea.

Dann Corbit wrote:
> The other query attempts given to me do not produce the desired
> results.  Thanks for taking a look anyway.
>
> Let me explain the problem set, and what I want to accomplish...
>
> I have two tables in all cases.  Each table pair consists of the
> following columns:
> 1.  A primary key of one or more columns {with a unique index}
> 2.  An Oid column {with a unique index}
> 3.  A 64 bit CRC
>
> For both tables, the primary key information will "mostly" match.  I
> need to know which primary keys are found in the first table but not in
> the second.  Also, which primary keys are found in the second table but
> not in the first.
>
> One possibility would be to add a tag column and set it where the two
> tables agree on primary key.  Unfortunately, we are likely to have many
> millions of rows (and only a few thousand disagreements) and so I would
> end up rewriting the entire table for both tables (less the tiny
> difference set) and hence that would be inefficient.   My outer join
> also stinks up the place.  (Several minutes for a million rows --
> unacceptable).
>
> Probably, I am going to have to write my own piece of custom software
> that manipulates the data outside of any database.  The database query
> approach is just too slow.
>
>