Re: sequential scan result order vs performance
| От | Andres Freund |
|---|---|
| Тема | Re: sequential scan result order vs performance |
| Дата | |
| Msg-id | 20161030074312.gm5iovv3hehxmtml@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | sequential scan result order vs performance (Andres Freund <andres@anarazel.de>) |
| Список | pgsql-hackers |
Hi, On 2016-10-30 00:36:55 -0700, Andres Freund wrote: > It's quite easy to change iteration so we start with the latest item, > and iterate till the first, rather than the other way round. In > benchmarks with somewhat wide columns and aggregation, this yields > speedups of over 30%, before hitting other bottlenecks. One more point: Over IM Robert commented that it's not guaranteed that itemid order correlates precisely with reverse "tuple data" order. After PageRepairFragmentation() that'll not be the case anymore. That's true, but I suspect in many cases with larger analytics queries the correlation will still be significant, and we also could make it guaranteed with the price of making PageRepairFragmentation() a bit more expensive. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: