| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: GIN fast insert |
| Date: | 2009-02-24 15:39:47 |
| Message-ID: | 9109.1235489987@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On my system this takes about 45 ms to execute with default settings
> and about 90 ms to execute with index scan disabled.
[ shrug... ] That's well within my threshold of pain for this.
In any case, it might be possible to buy some/all of that back with
minor optimization effort on the bitmap-scan code paths; nobody's
ever really bothered to profile that AFAIK. There is no real
difference in the useful work (page and tuple fetches) getting done
in the two cases, so there's no reason in principle for bitmap scan
to be much slower than indexscan here. The LIMIT case is the only
one I'm aware of where there's a fundamental reason that bitmap scan
should be slower.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tao Ma | 2009-02-24 15:41:12 | Re: question about the design consideration for system catalogs |
| Previous Message | Tom Lane | 2009-02-24 14:42:46 | Re: question about the design consideration for system catalogs |