Teodor Sigaev <teodor@sigaev.ru> writes:
>> We could extend IndexBuildHeapScan's API to support that, but I'm
>> not quite convinced that this is the issue.
> That extension might be useful for bitmap index too to simplify index creation
> process.
Maybe, but in any case the measurable GIN speed penalty justifies
changing it; I've applied a patch for that. I'm still not quite
convinced that Ivan isn't seeing some other issue though.
In the meantime, I noticed something odd while experimenting with your
test case: when running with default maintenance_work_mem = 16MB,
there is a slowdown of 3x or 4x for the un-ordered case, just as you
say. But at maintenance_work_mem = 200MB I see very little difference.
This doesn't make sense to me --- it seems like a larger workspace
should result in more difference because of greater chance to dump a
lot of tuples into the index at once. Do you know why that's happening?
regards, tom lane
