On Fri, Dec 11, 2015 at 5:35 PM, Peter Geoghegan <p...@heroku.com> wrote:
> On Fri, Dec 11, 2015 at 2:26 PM, Corey Huinker <corey.huin...@gmail.com>
> > Sure, the machine we called "ninefivealpha", which incidentally, failed
> > find a single bug in alpha2 thru beta2, is currently idle, and concurrent
> > index creation times are a bugbear around these parts. Can somebody,
> > in this thread or privately, outline what sort of a test they'd like to
> 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
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.