Tom Lane wrote:
Huh. As far as I can see this example should traverse the same code
path. I was about to ask for the dataset, but I think you might have
already sent it to me once --- does this look familiar?
$ tar tvfj geography.tar.bz2
-rw-r--r-- shade/shade 6444737 2008-06-06 13:33
Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk writes:
So in conclusion, I think that patch looks good and that the extra time
I was seeing was due to RECHECK being applied to the operator, and
not the time being spent within the index scan itself.
Thanks, I appreciate the followup.
I
On Sat, Aug 22, 2009 at 12:39:41PM -0400, Tom Lane wrote:
Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk writes:
So in conclusion, I think that patch looks good and that the extra time
I was seeing was due to RECHECK being applied to the operator, and
not the time being spent within
Tom Lane wrote:
There was recently another go-round on the postgis-devel list about
the same problem Mark Cave-Ayland complained about last year:
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00384.php
Basically, what is happening is a nestloop join where the inner
indexscan gets a
Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk writes:
Thanks for the patch. Fortunately enough I was able to find the dataset
from the original report above, and so I've tested your patch against
PostgreSQL 8.4. Unfortunately in the original test case, it doesn't seem
to give the same
Tom Lane wrote:
Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk writes:
Thanks for the patch. Fortunately enough I was able to find the dataset
from the original report above, and so I've tested your patch against
PostgreSQL 8.4. Unfortunately in the original test case, it doesn't seem
to
There was recently another go-round on the postgis-devel list about
the same problem Mark Cave-Ayland complained about last year:
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00384.php
Basically, what is happening is a nestloop join where the inner
indexscan gets a comparison argument
On Mon, 2009-08-17 at 13:37 -0400, Tom Lane wrote:
Thinking about it again, it seems to me that a much narrower patch
could solve the specific forms of the problem that the PostGIS folk
are seeing. Instead of trying to have a general-purpose method of
preventing repeat de-toasting, we could
Jeff Davis pg...@j-davis.com writes:
On Mon, 2009-08-17 at 13:37 -0400, Tom Lane wrote:
Thinking about it again, it seems to me that a much narrower patch
could solve the specific forms of the problem that the PostGIS folk
are seeing. Instead of trying to have a general-purpose method of
On Mon, 2009-08-17 at 14:54 -0400, Tom Lane wrote:
If so, is it possible that two similar plans for the same query might
perform differently due to repeated de-toasting?
Hard to answer that one. What's similar?
My only concern is that it's a somewhat hidden optimization (not seen in
On Mon, Aug 17, 2009 at 2:54 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Jeff Davis pg...@j-davis.com writes:
On Mon, 2009-08-17 at 13:37 -0400, Tom Lane wrote:
Thinking about it again, it seems to me that a much narrower patch
could solve the specific forms of the problem that the PostGIS folk
are
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 17, 2009 at 2:54 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Well, it solves the case people have actually complained about (twice
now). I originally attempted to solve a larger set of cases, but it's
not clear there's enough value in that.
12 matches
Mail list logo
