Re: GIN fast insert - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: GIN fast insert
Date
Msg-id 49956237.9020706@sigaev.ru
Whole thread Raw
In response to Re: GIN fast insert  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: GIN fast insert  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: GIN fast insert  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> So?  Barring some evidence that there's a significant performance win
> from a conventional indexscan, this is a weak argument.  AFAICS the only
> significant advantage of the conventional API is to support ordered
> scans, and GIN doesn't do that anyway.
What about  SELECT ... AND EXISTS (SELECT ... t @@ query) ?
But I don't believe that is popular use-case. In most cases, GIN is used with 
bitmap scan. Your emails are so convincing and I'll remove support amgettuple 
interface in GIN.

Do you think we need to add new pg_am boolean option? Like pg_am.amcangettuple 
or pg_am.amcanpertuplescan




-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Hot Standby: subxid cache changes
Next
From: Nikhil Sontakke
Date:
Subject: composite types DROP..CASCADE behaviour - bug or intentional?