Tom Lane wrote:
So you are saying it is de-toasted 32880 times, in this case? If not,
where are the repeated de-toastings happening?
Inside the index support functions. I'm thinking we could fix this by
forcibly detoasting values passed as index scan keys, but it's not quite
clear where's the
Tom Lane wrote:
Well, yeah, because the first thing it does is pg_detoast_datum.
Just as a cross-check, try changing it to copy the value without
forcibly detoasting --- I'll bet it's still slow then.
Yeah, that appears to be exactly the case. After some grepping through
various header files
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2008-06-09 at 11:49 -0400, Tom Lane wrote:
>> Is the value you are fetching from the geography table large enough to
>> be toasted? I'm thinking you might be looking at the cost of repeated
>> de-toastings.
> So you are saying it is de-toasted 328
On Mon, 2008-06-09 at 11:49 -0400, Tom Lane wrote:
> Mark Cave-Ayland <[EMAIL PROTECTED]> writes:
> > So by adding in an extra function around the subselect result, we have
> > speeded up the index lookup by several orders of magnitude, and the
> > speedup appears to be coming from somewhere wit
Mark Cave-Ayland <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Is the value you are fetching from the geography table large enough to
>> be toasted? I'm thinking you might be looking at the cost of repeated
>> de-toastings.
> Yeah, it's a fairly large geometry field so it will definitely be
>
Tom Lane wrote:
Is the value you are fetching from the geography table large enough to
be toasted? I'm thinking you might be looking at the cost of repeated
de-toastings.
Yeah, it's a fairly large geometry field so it will definitely be
getting toasted. So is it a case of with the mcatest fu
Mark Cave-Ayland <[EMAIL PROTECTED]> writes:
> So by adding in an extra function around the subselect result, we have
> speeded up the index lookup by several orders of magnitude, and the
> speedup appears to be coming from somewhere within the index scan?!
Is the value you are fetching from the
Simon Riggs wrote:
Hmmm, perhaps implicit casting?
Try this to see if it works better also
select count(*) from geography where centroid
&& (select the_geom::geometry from geography where id=69495);
Hi Simon,
Unfortunately that seems to take the slow runtime path too. I did
initially thi
On Mon, 2008-06-09 at 14:18 +0100, Mark Cave-Ayland wrote:
> Unfortunately I can't seem to work out why the extra time is
> disappearing into the index scan when my extra mcatest() function is
> not present,
Hmmm, perhaps implicit casting?
Try this to see if it works better also
select count(*
am Mon, dem 09.06.2008, um 14:18:50 +0100 mailte Mark Cave-Ayland folgendes:
> Hi there,
>
> I'm currently looking at a bug report in PostGIS where we are getting
> extremely long index scan times querying an index in one case, but the
> same scan can take much less time if the input geometry i
Hi there,
I'm currently looking at a bug report in PostGIS where we are getting
extremely long index scan times querying an index in one case, but the
same scan can take much less time if the input geometry is calculated as
the result of another function.
First of all, I include the EXPLAIN
11 matches
Mail list logo
