Re: 7.3 support for IN
От | Gregory Wood |
---|---|
Тема | Re: 7.3 support for IN |
Дата | |
Msg-id | 007301c22f2f$000ee620$7889ffcc@comstock.com обсуждение исходный текст |
Ответ на | 7.3 support for IN ("Gregory Wood" <gregw@com-stock.com>) |
Список | 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
В списке pgsql-general по дате отправления: