| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com> |
| Subject: | Re: Index usage for tstzrange? |
| Date: | 2013-03-22 22:53:14 |
| Message-ID: | 514CE0DA.5040109@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 22.03.2013 02:05, Josh Berkus wrote:
>> Well, no.<@ is not a btree-indexable operator.
>
> Yes, but it's equivalent to ( ( a>= b1 or b1 is null ) and ( a< b2 or
> b2 is null ) ), which *is* btree-indexable and can use an index. So it
> seems like the kind of optimization we could eventually make.
Yeah. The sort order of <@ is the same as regular b-tree, so it should
be possible. In fact, nothing stops you from creating the suitable
operator and b-tree support functions. See attached patch for int4, but
the same should work for timestamptz.
We should do this automatically. Or am I missing something?
- Heikki
| Attachment | Content-Type | Size |
|---|---|---|
| btree-support-for-int4-contained-by-int4range.sql | text/x-sql | 831 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2013-03-23 01:23:43 | Re: Index usage for tstzrange? |
| Previous Message | Cindy Makarowsky | 2013-03-22 22:26:36 | Re: Performance of query |