On Wed, 5 Aug 2009, Greg Stark wrote:
On Tue, Aug 4, 2009 at 11:56 PM, Robert Haasrobertmh...@gmail.com wrote:
Beats me. It looks like the first few queries are pulling stuff into
cache, and then after that it settles down, but I'm not sure why it
takes 5 repetitions to do that. Is the plan
On Wed, Aug 5, 2009 at 6:20 AM, Matthew Wakelingmatt...@flymine.org wrote:
It is certainly doing a sequential scan. So are you saying that it will
start a sequential scan from a different part of the table each time, even
in the absence of other simultaneous sequential scans? Looks like I'm
On Wed, 5 Aug 2009, Robert Haas wrote:
On Wed, Aug 5, 2009 at 6:20 AM, Matthew Wakelingmatt...@flymine.org wrote:
It is certainly doing a sequential scan. So are you saying that it will
start a sequential scan from a different part of the table each time, even
in the absence of other
Matthew Wakeling matt...@flymine.org writes:
It is certainly doing a sequential scan. So are you saying that it will
start a sequential scan from a different part of the table each time, even
in the absence of other simultaneous sequential scans?
Yeah, that's the syncscan logic biting you.
On Tue, Aug 4, 2009 at 12:06 PM, Matthew Wakelingmatt...@flymine.org wrote:
I'm seeing an interesting phenomenon while I'm trying to
performance-optimise a GiST index. Basically, running a performance test
appears to be the same thing as running a random number generator. For
example, here
On Tue, Aug 4, 2009 at 11:56 PM, Robert Haasrobertmh...@gmail.com wrote:
Beats me. It looks like the first few queries are pulling stuff into
cache, and then after that it settles down, but I'm not sure why it
takes 5 repetitions to do that. Is the plan changing?
Yeah, we're just guessing
