Teodor Sigaev <[EMAIL PROTECTED]> 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
