Re: sequential scan result order vs performance - Mailing list pgsql-hackers

From Andres Freund
Subject Re: sequential scan result order vs performance
Date
Msg-id 20161030074312.gm5iovv3hehxmtml@alap3.anarazel.de
Whole thread Raw
In response to sequential scan result order vs performance  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Greg Stark
Date:
Subject: Re: JIT compiler for expressions
Next
From: Andres Freund
Date:
Subject: Re: JIT compiler for expressions