On Thu, Dec 15, 2022 at 1:03 AM Sandro Santilli wrote:
>
> On Tue, Dec 13, 2022 at 11:31:05AM -0800, Paul Ramsey wrote:
> > Just to put a nail in this one: the last time our selectivity estimates for
> > Contains/Within were good was version 2.1, which used the && operator
> > instead of hte
On Tue, Dec 13, 2022 at 11:31:05AM -0800, Paul Ramsey wrote:
> Just to put a nail in this one: the last time our selectivity estimates for
> Contains/Within were good was version 2.1, which used the && operator instead
> of hte ~/@ operators in the SQL wrapper functions.
I think I was the one
expense of slightly less efficient index searching.
>
>> I thought we had others too about ST_covers but can't find any open ones.
>
> Hard to believe, but this might just be a very very very old bug.
>
> P.
>
>
>>
>>
>>> -Original Message---
is might just be a very very very old bug.
P.
>
>
> > -Original Message-
> > From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On
> Behalf
> > Of Paul Ramsey
> > Sent: Monday, December 12, 2022 5:57 PM
> > To: PostGIS Users Discussion
find any open ones.
> -Original Message-
> From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On
Behalf
> Of Paul Ramsey
> Sent: Monday, December 12, 2022 5:57 PM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] Row estimations
>
>
>From what I've been able to find out today, this bug may have existed
for a very long time. Firstly, the selectivity calculation is correct
(using your test setup).
=# select _postgis_selectivity('test'::regclass, 'p', 'POLYGON((0
0,0.8 0,0.8 0.8,0 0.8,0 0))');
_postgis_selectivity
> On Dec 9, 2022, at 10:11 AM, Igor ALBUQUERQUE SILVA
> wrote:
>
> In this example ST_Contains estimates 785 rows, while ST_Intersect estimates
> 615469 which is closer to the real 621571 rows. Using the bounding box
> operation I also obtain good estimations, and I also obtain good
04A400040494000404940'::geometry,
> p)
> > > Rows Removed by Filter: 4
> > > Planning Time: 0.121 ms
> > > Execution Time: 0.047 ms
> > >
> > > So the fact that works f
; > Execution Time: 0.047 ms
> >
> > So the fact that works for me and not you might be just dumb luck that I
> > ran the && first and the stats are cached and using that.
> >
> > The difference in answer might also be if you modified your
> > default_s
tistics_target.
>
> SHOW default_statistics_target;
>
> Mine shows 100.
>
> Thanks,
> Regina
>
>
> From: Regina Obe [mailto:l...@pcorp.us]
> Sent: Tuesday, December 6, 2022 8:59 PM
> To: 'PostGIS Users Discussion'
> Subject: RE: [postgis-users] Row estim
target.
SHOW default_statistics_target;
Mine shows 100.
Thanks,
Regina
From: Regina Obe [mailto:l...@pcorp.us]
Sent: Tuesday, December 6, 2022 8:59 PM
To: 'PostGIS Users Discussion'
Subject: RE: [postgis-users] Row estimations
Igor,
The stats estimation for PostGIS has always been
es seem odd to me that ST_Contains would give a higher estimate than
the && operation. That could be a bug in the function instrumentation of
ST_Contains and ST_Intersects.
Thanks,
Regina
From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On Behalf Of
Igor ALBUQUERQUE
Hello everyone,
I have a question regarding the row estimations/gist indexes. Here's a
minimal reproduction of it:
create table test(p geometry(point));
insert into test(p) values (st_makepoint(1,1));
insert into test(p) values (st_makepoint(1,2));
insert into test(p) values (st_makepoint(2,1));
13 matches
Mail list logo
