Re: [PATCH] Incremental sort (was: PoC: Partial sort)
| От | Tomas Vondra |
|---|---|
| Тема | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
| Дата | |
| Msg-id | 20200406195722.teiha6foiy3lix3s@development обсуждение исходный текст |
| Ответ на | Re: [PATCH] Incremental sort (was: PoC: Partial sort) (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
| Ответы |
Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Re: [PATCH] Incremental sort (was: PoC: Partial sort) Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
| Список | pgsql-hackers |
Hi, I've pushed the fist part of this patch series - I've reorganized it a bit by moving the add_partial_path changes to the end. That way I've been able to add regression test demonstrating impact of the change on plans involving incremental sort nodes (which wouldn't be possible when committing the add_partial_path first). I'll wait a bit before pushing the two additional parts, so that if something fails we know which bit caused it. I've been running extensive benchmarks with the aim to detect any regressions caused by this patch, particularly during planning. Attached is the script I've used and spreadsheet with results. The numbers show throughput with different queries (SELECT, EXPLANN and joins) with the patches committed one by one. There's quite a bit of noise, even though the script pins processes to cores and restricts CPU frequency. Overall, I don't see any obvious regression - the numbers are generally within 0.5% of the master, and the behavior is the same even with -M prepared which should not be subject to any planner overhead. I do have results from another machine (2-socket Xeon) but the results are much more noisy, although the general conclusions are about the same. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: