On Fri, Dec 11, 2015 at 5:35 PM, Peter Geoghegan <pg@heroku.com> wrote:
On Fri, Dec 11, 2015 at 2:26 PM, Corey Huinker <corey.huinker@gmail.com> wrote: > Sure, the machine we called "ninefivealpha", which incidentally, failed to > find a single bug in alpha2 thru beta2, is currently idle, and concurrent > index creation times are a bugbear around these parts. Can somebody, either > in this thread or privately, outline what sort of a test they'd like to see?
Any kind of CREATE INDEX CONCURRENTLY test, before and after.
I looked at a simple, random int4 column. That seems like a good case to focus on, since there isn't too much other overhead. I think I performed my test on an unlogged table, to make sure other overhead was even further minimized. -- Peter Geoghegan
What, if any, other load should be placed on the underlying table during the test?
I ask because CIC statements that run in seconds on our staging machine can take many hours on our production machine, when most of the access is just reads, though those reads may have been part of a larger transaction that did updates elsewhere.
