From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>, pgsql-general(at)postgresql(dot)org, Gianni Ciolli <gianni(dot)ciolli(at)2ndquadrant(dot)it> |
Subject: | Re: still gin index creation takes forever |
Date: | 2008-11-13 17:47:08 |
Message-ID: | 19090.1226598428@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Teodor Sigaev <teodor(at)sigaev(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Mason | 2008-11-13 18:13:54 | Re: simple COPY FROM issue |
Previous Message | Robert Fitzpatrick | 2008-11-13 17:14:44 | pgcrypto contrib |