| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:44:10 |
| Message-ID: | 49956B1A.8010101@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Teodor Sigaev wrote:
>> 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.
SELECT * FROM foo WHERE t @@ query LIMIT 100
might be a fairly common use case.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Teodor Sigaev | 2009-02-13 13:00:57 | Re: GIN fast insert |
| Previous Message | BogDan Vatra | 2009-02-13 12:29:39 | Re: SE-PostgreSQL and row level security |