Re: Performance question (stripped down the problem)
От | Steve Wolfe |
---|---|
Тема | Re: Performance question (stripped down the problem) |
Дата | |
Msg-id | 002101c14778$6f7d1300$50824e40@iboats.com обсуждение исходный текст |
Ответ на | Re: Performance question (stripped down the problem) (Herbert Liechti <herbert.liechti@thinx.ch>) |
Ответы |
Re: Performance question (stripped down the problem)
Re: Performance question (stripped down the problem) |
Список | pgsql-general |
> same here (dual PIII-866, Debian, 512 MB, raid1+0) > > real 0m6.472s > user 0m0.000s > sys 0m0.010s > > real 0m6.195s > user 0m0.010s > sys 0m0.000s > > real 0m2.885s > user 0m0.010s > sys 0m0.000s This is interesting, just yesterday I was perusing some of Bruce Momjian's works on PG tuning, and noticed that Postgres prefers sequential scans over indexes when much of the table has to be read, all because of the number of head movements on the disk. It would seem that these days, where RAM is cheap, that most people have a great enough disk cache that head movements can become irrelevant. However, I can also see where some people may have incredibly large tables that just won't fit into RAM. An easy solution to both might be to create a user-specifiable switch passed at startup that would simply tell PG that sequentials aren't necessarily better than index scans. Not completely disabling them, but at least giving it a pointer that it doesn't *have* to use sequentials. steve
В списке pgsql-general по дате отправления: