From: | Matthew Schumacher <matt(dot)s(at)aptalaska(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance problems testing with Spamassassin 3.1.0 |
Date: | 2005-08-04 16:17:58 |
Message-ID: | 42F23FB6.5010405@aptalaska.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane wrote:
> I don't really see why you think that this path is going to lead to
> better performance than where you were before. Manipulation of the
> temp table is never going to be free, and IN (sub-select) is always
> inherently not fast, and NOT IN (sub-select) is always inherently
> awful. Throwing a pile of simple queries at the problem is not
> necessarily the wrong way ... especially when you are doing it in
> plpgsql, because you've already eliminated the overhead of network
> round trips and repeated planning of the queries.
>
> regards, tom lane
The reason why I think this may be faster is because I would avoid
running an update on data that needs to be inserted which saves
searching though the table for a matching token.
Perhaps I should do the insert first, then drop those tokens from the
temp table, then do my updates in a loop.
I'll have to do some benchmarking...
schu
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-08-04 17:32:39 | Re: "nice"/low priority Query |
Previous Message | Tom Lane | 2005-08-04 16:16:10 | Re: Performance problems testing with Spamassassin 3.1.0 |