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 |
Subject: | Re: still gin index creation takes forever |
Date: | 2008-11-12 20:18:05 |
Message-ID: | 19874.1226521085@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:
>> I'm not following. Rightmost page of what --- it can't be the whole
>> index, can it, or the case would hardly ever apply?
> GIN's index contains btree over keys (entry tree) and for each key it
> contains list of ItemPointers (posting list) or btree over ItemPointers
> (posting tree or data tree) depending on its quantity. Bulk insertion
> process collects into memory keys and sorted arrays of ItemPointers, and
> then for each keys, it tries to insert every ItemPointer from array into
> corresponding data tree one by one. But if the smallest ItemPointer in
> array is greater than the biggest stored one then algorithm will insert
> the whole array on rightmost page in data tree.
> So, in that case process can insert about 1000 ItemPointers per one data
> tree lookup, in opposite case it does 1000 lookups in data tree.
I see. So this could explain Ivan's issue if his table contains large
numbers of repeated GIN keys. Ivan, is that what your data looks like?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Fitzpatrick | 2008-11-12 21:04:59 | Using dblink to connect as non-superuser |
Previous Message | paulo matadr | 2008-11-12 18:54:24 | Res: [GENERAL] MAX_CONNECTIONS ?? |