| From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: GIN fast insert |
| Date: | 2009-02-13 12:06:15 |
| Message-ID: | 49956237.9020706@sigaev.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikhil Sontakke | 2009-02-13 12:15:18 | composite types DROP..CASCADE behaviour - bug or intentional? |
| Previous Message | Heikki Linnakangas | 2009-02-13 11:07:32 | Re: Hot Standby: subxid cache changes |