On Fri, 8 Dec 2000, Tom Lane wrote:
> Date: Fri, 08 Dec 2000 12:59:27 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Oleg Bartunov <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], 'pgsql-hackers ' <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] Indexing for geographic objects?
>
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> >> 5000 looks like a suspiciously round number ... how many rows are in
> >> the table? Have you done a vacuum analyze on it?
>
> > about 10,000 rows,
>
> So the thing is estimating 0.5 selectivity, which is a fallback for
> operators it knows nothing whatever about.
>
> [ ... digs in Selkov's scripts ... ]
>
> CREATE OPERATOR @ (
> LEFTARG = seg, RIGHTARG = seg, PROCEDURE = seg_contains,
> COMMUTATOR = '~'
> );
>
> CREATE OPERATOR ~ (
> LEFTARG = seg, RIGHTARG = seg, PROCEDURE = seg_contained,
> COMMUTATOR = '@'
> );
>
> Sure 'nuff, no selectivity info attached to these declarations.
> Try adding
>
> RESTRICT = contsel, JOIN = contjoinsel
>
> to them. That's still an entirely bogus estimate, but at least
> it's a smaller bogus estimate ... small enough to select an indexscan,
> one hopes (see utils/adt/geo_selfuncs.c).
Great ! Now we have better plan:
test=# explain select * from test where s @ '1.05 .. 3.95';
NOTICE: QUERY PLAN:
Index Scan using test_seg_ix on test (cost=0.00..61.56 rows=100 width=12)
EXPLAIN
>
> I have not dug through Gene's stuff to see which other indexable
> operators might be missing selectivity estimates, but I'll bet there
> are others. If you have the time to look through it and submit a
> patch, I can incorporate it into the version that will go into contrib.
>
We didn't look at Gene's stuff yet. Maybe Gene could find a time to
check his code.
> regards, tom lane
>
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
