Обсуждение: spgist metapage
A quick survey of our various index AMs reveals that: 1. btree and hash indexes have a metapage that begins with a 32-bit magic number, followed by a 32-bit version number. 2. spgist has a metapage with a version number, but no magic number. 3. gin has a metapage with a version number that is not at the beginning of the structure, and no magic number. 4. gist indexes have no metapage at all. Since we haven't actually released spgist yet, I'm wondering if it should be revised to look more like btree and hash - that is, add a 32-bit version number immediately following the magic number. All experience hath shown that it is often much more work to add such things later. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> Since we haven't actually released spgist yet, I'm wondering if it
> should be revised to look more like btree and hash - that is, add a
> 32-bit version number immediately following the magic number. All
> experience hath shown that it is often much more work to add such
> things later.
With the beta already out, I think we have released it, for some
admittedly-small value of "released". I think it's too late to make
non-pg_upgrade-able changes on mere speculation that they might be a
good idea.
In any case, I would've expected we'd end up changing all these page
formats if we go over to your concept of a metapage for everything.
Fixing indexes that already have some kind of metapage will surely be
trivial compared to fixing heaps.
regards, tom lane
On Wed, May 23, 2012 at 2:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Since we haven't actually released spgist yet, I'm wondering if it >> should be revised to look more like btree and hash - that is, add a >> 32-bit version number immediately following the magic number. All >> experience hath shown that it is often much more work to add such >> things later. > > With the beta already out, I think we have released it, for some > admittedly-small value of "released". I think it's too late to make > non-pg_upgrade-able changes on mere speculation that they might be a > good idea. > > In any case, I would've expected we'd end up changing all these page > formats if we go over to your concept of a metapage for everything. > Fixing indexes that already have some kind of metapage will surely be > trivial compared to fixing heaps. I thought you might say that, but I thought I'd ask just in case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company