Re: B-Tree support function number 3 (strxfrm() optimization)
| От | Peter Geoghegan |
|---|---|
| Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
| Дата | |
| Msg-id | CAM3SWZQiGvGhMB4TMbEWoNjO17=ySB5b5Y5MGqJsaNq4uWTryA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: B-Tree support function number 3 (strxfrm() optimization) (Peter Geoghegan <pg@heroku.com>) |
| Ответы |
Re: B-Tree support function number 3 (strxfrm() optimization)
|
| Список | pgsql-hackers |
On Wed, Aug 6, 2014 at 10:36 PM, Peter Geoghegan <pg@heroku.com> wrote: > This *almost* applies to patched Postgres if you pick a benchmark that > is very sympathetic to my patch. To my surprise, work_mem = '10MB' > (which results in an external tape sort) is sometimes snapping at the > heels of a work_mem = '5GB' setting (which results in an in-memory > quicksort). Note that this was with a default temp_tablespaces setting that wrote temp files on my home partition/SSD. With a /dev/shm/ temp tablespace, tape sort edges ahead, and has a couple of hundred milliseconds on quicksort for this test case. It's actually faster. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: