| From: | "Gregory Wood" <gregw(at)com-stock(dot)com> | 
|---|---|
| To: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org> | 
| Cc: | "PostgreSQL-General" <pgsql-general(at)postgresql(dot)org> | 
| Subject: | Re: 7.3 support for IN | 
| Date: | 2002-07-19 14:12:25 | 
| Message-ID: | 007301c22f2f$000ee620$7889ffcc@comstock.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
> > 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lee Kindness | 2002-07-19 14:27:19 | Re: Looking for types: phone number, email addresses | 
| Previous Message | Stephane Bortzmeyer | 2002-07-19 14:07:24 | Re: Looking for types: phone number, email addresses |