> > Before anyone starts thinking it, yes, I am aware that INs are really
slow
> > in PostgreSQL. That being said... I was doing some tests with big IN
> > statements and various workarounds and was shocked at some of the
results.
>
> I hope those values were averaged out over a few runs. Measuring something
as
> 16ms with a single run makes it statistically invalid. Maybe PostgreSQL
> happened to lose it's timeslice just as the EXISTS query came along,
blowing
> any results completely out of the water.
Actually I ran the queries several times until I got consistent results
three or four times consecutively. In the case of 2 digit times (the 16 and
31 ms) they were within tenths of a second of each other. In the case of the
hundred ms+ times, the range was about 10ms, I tried to pick the 10s value
that they tended to cluster around (for example 930 might have been 934.23,
928.61 and 929.47).
If I got an inconsistent result I would run the query another 5 or 10 times
to be sure that I had what I considered the most consistent times. Very
rough I know, but I'm pretty sure that none of those numbers represents a
'blip' in performance.
Of course multiple runs like this pretty much ensures that everything is
thrown into cache, but I'm hoping to keep most if not all of the DB in
memory anyway.
Greg