Re: Tuplesort merge pre-reading
От | Heikki Linnakangas |
---|---|
Тема | Re: Tuplesort merge pre-reading |
Дата | |
Msg-id | b353e579-a5d2-fff9-5c89-ef43244c7964@iki.fi обсуждение исходный текст |
Ответ на | Re: Tuplesort merge pre-reading (Claudio Freire <klaussfreire@gmail.com>) |
Ответы |
Re: Tuplesort merge pre-reading
|
Список | pgsql-hackers |
On 09/22/2016 03:40 AM, Claudio Freire wrote: > On Tue, Sep 20, 2016 at 3:34 PM, Claudio Freire <klaussfreire@gmail.com> wrote: >> The results seem all over the map. Some regressions seem significant >> (both in the amount of performance lost and their significance, since >> all 4 runs show a similar regression). The worst being "CREATE INDEX >> ix_lotsofitext_zz2ijw ON lotsofitext (z, z2, i, j, w);" with 4GB >> work_mem, which should be an in-memory sort, which makes it odd. >> >> I will re-run it overnight just in case to confirm the outcome. > > A new run for "patched" gives better results, it seems it was some > kind of glitch in the run (maybe some cron decided to do something > while running those queries). > > Attached > > In essence, it doesn't look like it's harmfully affecting CPU > efficiency. Results seem neutral on the CPU front. Looking at the spreadsheet, there is a 40% slowdown in the "slow" "CREATE INDEX ix_lotsofitext_zz2ijw ON lotsofitext (z, z2, i, j, w);" test with 4GB of work_mem. I can't reproduce that on my laptop, though. Got any clue what's going on there? - Heikki
В списке pgsql-hackers по дате отправления: