Updated: http://www.sigaev.ru/misc/fast_insert_gin-0.9.gz
need more review of fast_insert yet? It looked like a number of people
commented on it already.
I still havn't clearness of acceptability for suggested aminsertcleanup
calling.
--
Teodor Sigaev E
I've committed the multicolumn one with minor revisions (fix some poor
English in docs and comments, add regression-test coverage). Do you
Thank you very much.
need more review of fast_insert yet? It looked like a number of people
commented on it already.
I should modify it to support/synchro
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> http://www.sigaev.ru/misc/fast_insert_gin-0.7.gz
> http://www.sigaev.ru/misc/multicolumn_gin-0.3.gz
I've committed the multicolumn one with minor revisions (fix some poor
English in docs and comments, add regression-test coverage). Do you
need more revi
Neil,
> I was tasked with reviewing this for the current commit fest, although
> so far I've just been working on grokking the rest of the GIN code. But
> if you'd like to review it instead, that's fine with me.
I have plenty of other stuff I could assign you if you're not needed on
GIN.
--
--
On Tue, 2008-07-08 at 14:51 -0400, Tom Lane wrote:
> I'd still like to take a look.
I was tasked with reviewing this for the current commit fest, although
so far I've just been working on grokking the rest of the GIN code. But
if you'd like to review it instead, that's fine with me.
-Neil
--
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> I looked this over and it looks good in general.
> May I think that patch passed review and commit it?
I'd still like to take a look.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To
I looked this over and it looks good in general.
May I think that patch passed review and commit it?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list
Teodor Sigaev wrote:
>> I looked this over and it looks good in general. I was only wondering
>> about for single-column indexes -- we're storing attribute numbers too,
>> right?
> No, GinState->oneCol field signals to GinFormTuple and
> gin_index_getattr/gintuple_get_attrnum about actual storag
I looked this over and it looks good in general. I was only wondering
about for single-column indexes -- we're storing attribute numbers too,
right?
No, GinState->oneCol field signals to GinFormTuple and
gin_index_getattr/gintuple_get_attrnum about actual storage.
Single column index is binary
Teodor Sigaev wrote:
> Sync with current CVS HEAD and post in hackers- too because patches-
> close to the closing.
>
> http://www.sigaev.ru/misc/multicolumn_gin-0.3.gz
I looked this over and it looks good in general. I was only wondering
about for single-column indexes -- we're storing attribut
Sync with current CVS HEAD and post in hackers- too because patches- close to
the closing.
http://www.sigaev.ru/misc/fast_insert_gin-0.7.gz
http://www.sigaev.ru/misc/multicolumn_gin-0.3.gz
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> So, I didn't see any comments/objections and I intend to commit this patch
> for
> next two days and synchronize 'fast insert into GIN' patch with CVS.
> Objections?
I think it hasn't really gotten reviewed at all (certainly not by me).
If you want oth
1) multicolumn GIN
Unlike other indexes, the performance of search
doesn't depends on what column of index (first, last, any subset) is
used in search clause. This property can be used in gincostestimate, but
I haven't looked on it yet.
After some playing I didn't find any mentions in *cost
Right now this is not a problem because there is no insert_cleanup
function for btree, but I wonder if we should clean it up.
Look at gistbulkdelete and gistvacuumcleanup, first function wants to send a
bool flag to second one and they use GiSTBulkDelete structure instead of usual
IndexBulkDelet
Perhaps we could make the fixed-size buffer be of size X, and trigger
autovac on X/3 or some such, to give it enough slack so that it would be
very unlikely to be processed by user processes.
Do you mean that GIN sends a "smoke signal" to the autovacuum launcher
process to ask about vacuum?
Curr
Teodor Sigaev wrote:
>
>> 2) fast insert into GIN
> New version:
> http://www.sigaev.ru/misc/fast_insert_gin-0.6.gz
>
> Changes:
> - added option FASTUPDATE=(1|t|true|on|enable|0|f|false|disable) for
> CREATE/ALTER command for GIN indexes
> - Since there wasn't any comments on first email, pg_am.
Teodor Sigaev wrote:
>> How about having a constant sized "fastupdate" buffer, of say 100 rows
>> or a fixed number of pages, and when that becomes full, the next
>> inserter will have to pay the price of updating the index and flushing
>
> I'm not sure that is acceptable because flushing pend
How about having a constant sized "fastupdate" buffer, of say 100 rows
or a fixed number of pages, and when that becomes full, the next
inserter will have to pay the price of updating the index and flushing
I'm not sure that is acceptable because flushing pending list may take several
seconds
Teodor Sigaev wrote:
2) fast insert into GIN
New version:
http://www.sigaev.ru/misc/fast_insert_gin-0.6.gz
Changes:
- added option FASTUPDATE=(1|t|true|on|enable|0|f|false|disable) for
CREATE/ALTER command for GIN indexes
I think we should try to make it automatic. I'm not sure how.
How
2) fast insert into GIN
New version:
http://www.sigaev.ru/misc/fast_insert_gin-0.6.gz
Changes:
- added option FASTUPDATE=(1|t|true|on|enable|0|f|false|disable) for
CREATE/ALTER command for GIN indexes
- Since there wasn't any comments on first email, pg_am.aminsertcleanup optional
method w
Improvements of GIN indexes were presented on PGCon 2008. Presentation:
http://www.sigaev.ru/gin/fastinsert_and_multicolumn_GIN.pdf
1) multicolumn GIN
This patch ( http://www.sigaev.ru/misc/multicolumn_gin-0.2.gz ) adds multicolumn
support to GIN. The basic idea is: keys (entries in GIN termin
21 matches
Mail list logo
