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 Raw
In response to Re: sequential scan result order vs performance  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
<div dir="ltr"><div class="gmail_extra"><br /><div class="gmail_quote">On Sun, Oct 30, 2016 at 11:37 PM, Jim Nasby
<spandir="ltr"><<a href="mailto:Jim.Nasby@bluetreble.com" target="_blank">Jim.Nasby@bluetreble.com</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">BTW,
I'vesometimes wished for a mode where queries would silently have result ordering intentionally futzed, to eliminate
anypossibility of dependence on tuple ordering (as well as having sequences start at some random value). I guess with
thehooks that are in place today it wouldn't be hard to stick a ORDER BY random() in if there wasn't already a Sort
nodeat the top level...</blockquote></div><div class="gmail_extra"><br /></div>+1<br />In Oracle, we sorta had that
featureby adding a parallel hint to a query even if it didn't need it. It came in handy.</div></div> 

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