Re: btree_gin and ranges
От | Heikki Linnakangas |
---|---|
Тема | Re: btree_gin and ranges |
Дата | |
Msg-id | 5491D5E4.10905@vmware.com обсуждение исходный текст |
Ответ на | btree_gin and ranges (Teodor Sigaev <teodor@sigaev.ru>) |
Ответы |
Re: btree_gin and ranges
|
Список | pgsql-hackers |
On 10/22/2014 01:55 PM, Teodor Sigaev wrote: > Suggested patch adds GIN support contains operator for ranges over scalar column. > > It allows more effective GIN scan. Currently, queries like > SELECT * FROM test_int4 WHERE i <= 1 and i >= 1 > will be excuted by GIN with two scans: one is from mines infinity to 1 and > another is from -1 to plus infinity. That's because GIN is "generalized" and it > doesn't know a semantics of operation. > > With patch it's possible to rewrite query with ranges > SELECT * FROM test_int4 WHERE i <@ '[-1, 1]'::int4range > and GIN index will support this query with single scan from -1 to 1. > > Patch provides index support only for existing range types: int4, int8, numeric, > date and timestamp with and without time zone. I started to look at this, but very quickly got carried away into refactoring away the macros. Defining long functions as macros makes debugging quite difficult, and it's not nice to read or edit the source code either. I propose the attached refactoring (it doesn't include your range-patch yet, just refactoring the existing code). It turns the bulk of the macros into static functions. GIN_SUPPORT macro still defines the datatype-specific functions, but they are now very thin wrappers that just call the corresponding generic static functions. It's annoying that we need the concept of a leftmost value, for the < and <= queries. Without that, we could have the support functions look up the required datatype information from the type cache, based on the datatype of the passed argument. Then you could easily use the btree_gin support functions also for user-defined datatypes. But that needs bigger changes, and this is a step in the right direction anyway. - Heikki
Вложения
В списке pgsql-hackers по дате отправления: