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
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
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
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
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 <
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
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
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
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
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
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
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
12 matches
Mail list logo