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

From Corey Huinker
Subject Re: sequential scan result order vs performance
Date
Msg-id CADkLM=f43+ceZc0YYy_U+-7aDcbczuJrPp-L+k+bw7qgZNwd=g@mail.gmail.com
Whole thread
In response to Re: sequential scan result order vs performance  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers

On Sun, Oct 30, 2016 at 11:37 PM, Jim Nasby <Jim.Nasby@bluetreble.com> 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 with the hooks that are in place today it wouldn't be hard to stick a ORDER BY random() in if there wasn't already a Sort node at the top level...

+1
In Oracle, we sorta had that feature by adding a parallel hint to a query even if it didn't need it. It came in handy.

pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: COPY as a set returning function
Next
From: Tomas Vondra
Date:
Subject: Re: Speed up Clog Access by increasing CLOG buffers