Re: [HACKERS] sequential scan result order vs performance

2016-10-31 Thread Corey Huinker
On Sun, Oct 30, 2016 at 11:37 PM, Jim Nasby wrote: > BTW, I've sometimes wished for a mode where queries would silently have > result ordering intentionally futzed, to eliminate any possibility of > dependence on tuple ordering (as well as having sequences start at some > random value). I guess w

Re: [HACKERS] sequential scan result order vs performance

2016-10-31 Thread Dagfinn Ilmari Mannsåker
Jim Nasby writes: > BTW, I've sometimes wished for a mode where queries would silently have > result ordering intentionally futzed, to eliminate any possibility of > dependence on tuple ordering (as well as having sequences start at some > random value). FWIW, SQLite has this, in the form of 'PR

Re: [HACKERS] sequential scan result order vs performance

2016-10-31 Thread Albe Laurenz
Jim Nasby wrote: > On 10/30/16 9:12 AM, Tom Lane wrote: >> I think there will be a lot of howls. People expect that creating >> a table by inserting a bunch of rows, and then reading back those >> rows, will not change the order. We already futzed with that guarantee >> a bit with syncscans, but

Re: [HACKERS] sequential scan result order vs performance

2016-10-30 Thread Jim Nasby
On 10/30/16 9:12 AM, Tom Lane wrote: I think there will be a lot of howls. People expect that creating a table by inserting a bunch of rows, and then reading back those rows, will not change the order. We already futzed with that guarantee a bit with syncscans, but that only affects quite large

Re: [HACKERS] sequential scan result order vs performance

2016-10-30 Thread Tom Lane
Andres Freund writes: > 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. > I do won

Re: [HACKERS] sequential scan result order vs performance

2016-10-30 Thread Andres Freund
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 hitti

[HACKERS] sequential scan result order vs performance

2016-10-30 Thread Andres Freund
Hi, while working on the executor, to process "batches" or "bubbles" of tuples I hit some weird performance issues (as in things didn't improve as much as I had hoped). A fair amount of headscratching later I figured out that the tuple order in sequential scans is a major bottleneck. When iterat