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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
