Thread: Re: [COMMITTERS] pgsql: Implement "fastupdate" support for GIN indexes, in which we try
Re: [COMMITTERS] pgsql: Implement "fastupdate" support for GIN indexes, in which we try
From
Robert Haas
Date:
2009/3/24 Tom Lane <tgl@postgresql.org>: > Implement "fastupdate" support for GIN indexes, in which we try to accumulate > multiple index entries in a holding area before adding them to the main index > structure. This helps because bulk insert is (usually) significantly faster > than retail insert for GIN. > > This patch also removes GIN support for amgettuple-style index scans. The > API defined for amgettuple is difficult to support with fastupdate, and > the previously committed partial-match feature didn't really work with > it either. We might eventually figure a way to put back amgettuple > support, but it won't happen for 8.4. > > catversion bumped because of change in GIN's pg_am entry, and because > the format of GIN indexes changed on-disk (there's a metapage now, > and possibly a pending list). Will this break pg_migrator? ...Robert
Re: Re: [COMMITTERS] pgsql: Implement "fastupdate" support for GIN indexes, in which we try
From
Tom Lane
Date:
Robert Haas <robertmhaas@gmail.com> writes:
> 2009/3/24 Tom Lane <tgl@postgresql.org>:
>> catversion bumped because of change in GIN's pg_am entry, and because
>> the format of GIN indexes changed on-disk (there's a metapage now,
>> and possibly a pending list).
> Will this break pg_migrator?
No worse than it's already broken by hash indexes. I would imagine
the strategy will just be to force a REINDEX on any non-btree indexes.
regards, tom lane
Re: Re: [COMMITTERS] pgsql: Implement "fastupdate" support for GIN indexes, in which we try
From
Bruce Momjian
Date:
Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > 2009/3/24 Tom Lane <tgl@postgresql.org>: > >> catversion bumped because of change in GIN's pg_am entry, and because > >> the format of GIN indexes changed on-disk (there's a metapage now, > >> and possibly a pending list). > > > Will this break pg_migrator? > > No worse than it's already broken by hash indexes. I would imagine > the strategy will just be to force a REINDEX on any non-btree indexes. Agreed. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +