On Sat, 2012-05-26 at 15:14 -0400, Tom Lane wrote:
3. Having now spent a good deal of time poking at this, I think that the
syncscan logic is in need of more tuning, and I am wondering whether we
should even have it turned on by default. It appears to be totally
useless for
Jeff Davis pg...@j-davis.com writes:
On Sat, 2012-05-26 at 15:14 -0400, Tom Lane wrote:
3. Having now spent a good deal of time poking at this, I think that the
syncscan logic is in need of more tuning, and I am wondering whether we
should even have it turned on by default. It appears to be
On Sat, May 26, 2012 at 03:14:18PM -0400, Tom Lane wrote:
It seems clear to me that we should just disable syncscans for the
relcache reload heapscans. There is lots of downside due to breaking
the early-exit optimization in RelationBuildTupleDesc, and basically no
upside. I'm inclined to
Noah Misch n...@leadboat.com writes:
On Sat, May 26, 2012 at 03:14:18PM -0400, Tom Lane wrote:
It seems clear to me that we should just disable syncscans for the
relcache reload heapscans. There is lots of downside due to breaking
the early-exit optimization in RelationBuildTupleDesc, and
I've been poking at Jeff Frost's and Greg Mullane's recent reports of
high load due to many processes getting stuck in relcache init file
rebuild operations. I can reproduce a similar behavior here by creating
a database containing a whole lot of many-column views, thereby bloating
pg_attribute
