aboutsummaryrefslogtreecommitdiff
path: root/src/backend/tcop/postgres.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2015-01-12 15:13:28 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2015-01-12 15:13:53 -0500
commit5b3ce2c911a2ec9de13b0dea7e135ad945a14583 (patch)
treee4203853ccfe25c3d3902b6a1ee7e25fc49c19e5 /src/backend/tcop/postgres.c
parentd126e1e95fab44cc73002de3eaa08e2d88f11c50 (diff)
downloadpostgresql-5b3ce2c911a2ec9de13b0dea7e135ad945a14583.tar.gz
postgresql-5b3ce2c911a2ec9de13b0dea7e135ad945a14583.zip
Avoid unexpected slowdown in vacuum regression test.
I noticed the "vacuum" regression test taking really significantly longer than it used to on a slow machine. Investigation pointed the finger at commit e415b469b33ba328765e39fd62edcd28f30d9c3c, which added creation of an index using an extremely expensive index function. That function was evidently meant to be applied only twice ... but the test re-used an existing test table, which up till a couple lines before that had had over two thousand rows. Depending on timing of the concurrent regression tests, the intervening VACUUMs might have been unable to remove those recently-dead rows, and then the index build would need to create index entries for them too, leading to the wrap_do_analyze() function being executed 2000+ times not twice. Avoid this by using a different table that is guaranteed to have only the intended two rows in it. Back-patch to 9.0, like the commit that created the problem.
Diffstat (limited to 'src/backend/tcop/postgres.c')
0 files changed, 0 insertions, 0 deletions