Re: GIN fast insert
От | Robert Haas |
---|---|
Тема | Re: GIN fast insert |
Дата | |
Msg-id | 603c8f070902240746n1a4c9facu9554407330369474@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GIN fast insert (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Feb 24, 2009 at 10:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.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. Uh, a semi or anti join stops as soon as one matching row is found, doesn't it? ISTM that a semi or anti join is in essence an iterated limit 1 clause. ...Robert
В списке pgsql-hackers по дате отправления: