Re: sequential scan result order vs performance
От | Corey Huinker |
---|---|
Тема | Re: sequential scan result order vs performance |
Дата | |
Msg-id | CADkLM=f43+ceZc0YYy_U+-7aDcbczuJrPp-L+k+bw7qgZNwd=g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: sequential scan result order vs performance (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Список | 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 по дате отправления: