Re: Scalar in a range (but textual not numeric) - Mailing list pgsql-sql

From Richard Huxton
Subject Re: Scalar in a range (but textual not numeric)
Date
Msg-id 200402252208.55502.dev@archonet.com
Whole thread Raw
In response to Re: Scalar in a range (but textual not numeric)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Scalar in a range (but textual not numeric)
List pgsql-sql
On Wednesday 25 February 2004 21:32, Tom Lane wrote:
> Richard Huxton <dev@archonet.com> 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


pgsql-sql by date:

Previous
From: Tom Lane
Date:
Subject: Re: Scalar in a range (but textual not numeric)
Next
From: Richard Huxton
Date:
Subject: Re: Scalar in a range (but textual not numeric)