<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 11, 2015 at 5:35 PM, Peter Geoghegan <span
dir="ltr"><<ahref="mailto:pg@heroku.com" target="_blank">pg@heroku.com</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Dec 11,
2015at 2:26 PM, Corey Huinker <<a href="mailto:corey.huinker@gmail.com">corey.huinker@gmail.com</a>> wrote:<br />
>Sure, the machine we called "ninefivealpha", which incidentally, failed to<br /> > find a single bug in alpha2
thrubeta2, is currently idle, and concurrent<br /> > index creation times are a bugbear around these parts. Can
somebody,either<br /> > in this thread or privately, outline what sort of a test they'd like to see?<br /><br
/></span>Anykind of CREATE INDEX CONCURRENTLY test, before and after.<br /><br /> I looked at a simple, random int4
column.That seems like a good case<br /> to focus on, since there isn't too much other overhead. I think I<br />
performedmy test on an unlogged table, to make sure other overhead<br /> was even further minimized.<br /><span
class="HOEnZb"><fontcolor="#888888"><br /> --<br /> Peter Geoghegan<br /></font></span></blockquote></div><br
/></div><divclass="gmail_extra">What, if any, other load should be placed on the underlying table during the
test?</div><divclass="gmail_extra"><br /></div><div class="gmail_extra">I ask because CIC statements that run in
secondson our staging machine can take many hours on our production machine, when most of the access is just reads,
thoughthose reads may have been part of a larger transaction that did updates elsewhere.</div><div
class="gmail_extra"><br/></div><div class="gmail_extra"><br /></div><div class="gmail_extra"><br /></div><div
class="gmail_extra"><br/></div><div class="gmail_extra"><br /></div></div>
