My guess is that it will manifest only with tables of large objects, particularly if they break the toast barrier. I am still waiting for a sample data set I can download, that link didn't work for me at all.
P. On Fri, Aug 14, 2009 at 9:15 AM, Kevin Neufeld<[email protected]> wrote: > Paragon Corporation wrote: >> >> Kevin et al, >> >> Interesting. What is there to discover? That you can force choice of >> index? >> > > No, not that you can force the planner. You'll notice in my 3 examples, the > first and the last queries have the exact same plan, but the 3rd runs in > half the time. > > What's interesting here is that postgresql is caching expand() calls > differently than a simple &&, improving I/O performance significantly. > > [time passes] > Ok, so, I just did a bunch more testing on 8.2 and 8.3 and it turns out that > I can't reproduce the results on any of the newer postgis installs (1.4.0, > 1.4.1SVN). The version I was using to yield the strange caching behaviour > was (shamefully) 1.1 running on 8.2. > > So I withdrawn my previous "discover" comments :) > > -- Kevin > _______________________________________________ > postgis-users mailing list > [email protected] > http://postgis.refractions.net/mailman/listinfo/postgis-users > _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
