On Wednesday 25 February 2004 21:32, Tom Lane wrote:
> Richard Huxton <[EMAIL PROTECTED]> writes:
> > Large table representing non-overlapping blocks:
> > blocks(id int4, min varchar, max varchar)
> >
> > SELECT * FROM blocks WHERE 'ABCDE' BETWEEN min AND max;
> >
> > The estimator gets the wrong plan because it doesn't realise there's
> > (at most) only one block that can match.
>
> Even if it did realize that, it couldn't do much, because this query
> isn't indexable as it stands.
Well, it is in the sense that an index can be used. Here I'd defined pkey as
(min,max,id) and set enable_seqscan=off
-> Index Scan using prnblock_range_pkey on prnblock_range
(cost=0.00..1403.99 rows=892 width=33) (actual time=23.88..24.07 rows=1
loops=1)
Index Cond: (('09050091234'::character varying >= pr_min) AND
('09050091234'::character varying <= pr_max))
Of course, what I really want is a "varchar_range" type with its own
indexing...
> I wonder whether you could adapt the "line segment" datatype
> (see contrib/seg/) into a sort of "text segment" thingy and use the
> GiST indexing support on that. You'd have a query like
> WHERE min_max_object overlaps-operator 'ABCDE'
> and the overlaps operator would be a GiST-indexable one.
Yep, that's the sort of thing I was wanting, just not worth the trouble in
this case. It's not the heart of the system, only a corner case.
Thanks anyway Tom
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
