Re: [HACKERS] btree_gin and ranges

2015-03-20 Thread Alvaro Herrera
Teodor Sigaev wrote: > >Teodor's patch could use some more comments. The > >STOP_SCAN/MATCH_SCAN/CONT_SCAN > >macros are a good idea, but they probably should go into > >src/include/access/gin.h so that they can be used in all compare_partial > >implementations. > > STOP_SCAN/MATCH_SCAN/CONT_SCAN

Re: [HACKERS] btree_gin and ranges

2015-03-19 Thread Bruce Momjian
On Fri, Dec 26, 2014 at 01:33:26PM +0300, Teodor Sigaev wrote: > >Teodor's patch could use some more comments. The > >STOP_SCAN/MATCH_SCAN/CONT_SCAN > >macros are a good idea, but they probably should go into > >src/include/access/gin.h so that they can be used in all compare_partial > >implementa

Re: [HACKERS] btree_gin and ranges

2014-12-26 Thread Teodor Sigaev
Teodor's patch could use some more comments. The STOP_SCAN/MATCH_SCAN/CONT_SCAN macros are a good idea, but they probably should go into src/include/access/gin.h so that they can be used in all compare_partial implementations. STOP_SCAN/MATCH_SCAN/CONT_SCAN macros are moved to gin's header, and

Re: [HACKERS] btree_gin and ranges

2014-12-22 Thread Heikki Linnakangas
On 12/22/2014 03:15 AM, Michael Paquier wrote: On Thu, Dec 18, 2014 at 4:13 AM, Heikki Linnakangas wrote: 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

Re: [HACKERS] btree_gin and ranges

2014-12-21 Thread Michael Paquier
On Thu, Dec 18, 2014 at 4:13 AM, Heikki Linnakangas wrote: > 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 <

Re: [HACKERS] btree_gin and ranges

2014-12-17 Thread Heikki Linnakangas
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 infi

Re: [HACKERS] btree_gin and ranges

2014-10-24 Thread Teodor Sigaev
which would also be nice to fix.. Of course, agree. With rbtree usage instead of tidbitmap hash and semantic knowledge about operators in GIN... -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sig

Re: [HACKERS] btree_gin and ranges

2014-10-24 Thread Heikki Linnakangas
On 10/22/2014 03:01 PM, Teodor Sigaev wrote: Anyway GIN couldn't be used for ORDER BY clause. which would also be nice to fix... - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hack

Re: [HACKERS] btree_gin and ranges

2014-10-24 Thread Heikki Linnakangas
On 10/22/2014 03:01 PM, Teodor Sigaev wrote: Anyway GIN couldn't be used for ORDER BY clause. which would also be nice to fix... - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hack

Re: [HACKERS] btree_gin and ranges

2014-10-22 Thread Teodor Sigaev
Shouldn't this be implemented in a more generic manner? An ordinary Unfortunately I don't see a way for that. GIN is generalized - and it doesn't know semantic. Actually, we could fix first five strategy numbers for BTree's strategies, and then we could teach GIN core to use BTRee semantic, but

Re: [HACKERS] btree_gin and ranges

2014-10-22 Thread Marti Raudsepp
Hi On Wed, Oct 22, 2014 at 1:55 PM, Teodor Sigaev wrote: > 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. Shouldn't this be implemented in a more generic manner

[HACKERS] btree_gin and ranges

2014-10-22 Thread Teodor Sigaev
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 infi