On Sat, Aug 22, 2009 at 12:39:41PM -0400, Tom Lane wrote:
> Mark Cave-Ayland 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.
>
Mark Cave-Ayland 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 plan to go ahead and apply th
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 geograp
Tom Lane wrote:
Mark Cave-Ayland 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 performance improvem
Mark Cave-Ayland 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 performance improvement for me
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 com
Robert Haas writes:
> On Mon, Aug 17, 2009 at 2:54 PM, Tom Lane 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.
> How related is this issue?
> http
On Mon, Aug 17, 2009 at 2:54 PM, Tom Lane wrote:
> Jeff Davis 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 try
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 i
Jeff Davis 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
>> preventing r
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 coul
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 fr
12 matches
Mail list logo
