Thread: [PATCH] Partial indices almost there
Well, I've done the patch against the latest CVS this time, making it easier to merge in later. Major features: * You can create partial indices * You can pg_dump them * They have documentation * The database will use them * Disables EXTEND INDEX pending complete removal Remaining issue: * Vacuum destroys your index's partialness I'm going to work on that tonight, I'll see how far I get. You'll need to do an initdb after this (I think) because it adds a new internal function. I used OID 1716, I hope nobody is using that one right now. http://svana.org/kleptog/pgsql/partial-indices-7.2.patch -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > It would be nice if someone came up with a certification system that > actually separated those who can barely regurgitate what they crammed over > the last few weeks from those who command secret ninja networking powers.
> You'll need to do an initdb after this (I think) because it adds a new
> internal function. I used OID 1716, I hope nobody is using that one right
> now.
>
I asked this one myself not too long ago :-)
There's a shell script:
~/pgsql/src/include/catalog/unused_oids
which will shown you the available oids.
HTH,
Joe
On Tue, Jul 10, 2001 at 10:58:41PM -0700, Joe Conway wrote: > > You'll need to do an initdb after this (I think) because it adds a new > > internal function. I used OID 1716, I hope nobody is using that one right > > now. > > > > I asked this one myself not too long ago :-) > > There's a shell script: > ~/pgsql/src/include/catalog/unused_oids Thanks. I did use the script and it says it's free. But maybe someone else has a patch somewhere else right now wnho is using it. The only way we'll find out is if they both get added and somebody notices. Does somewhere check for duplicate oids? -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > It would be nice if someone came up with a certification system that > actually separated those who can barely regurgitate what they crammed over > the last few weeks from those who command secret ninja networking powers.
Martijn van Oosterhout <kleptog@svana.org> writes:
> Does somewhere check for duplicate oids?
The duplicate_oids script in the same directory.
In practice, what really matters is that no two entries in the same
system catalog have the same OID; it wouldn't matter if we had, say,
the same OID used by a pg_proc and a pg_am entry. In some catalogs
it doesn't matter at all because we never do lookups by OID (this is
true for pg_attribute, for example *). We have a unique index on OID
on every system catalog where it matters, and ultimately that is what
ensures validity of the OID assignments. Keeping the hand-assigned
OIDs unique across the whole system is just a matter of neatnik-ism.
regards, tom lane
* In fact, Patricia Holben noticed awhile back that there *are*
duplicate OIDs in pg_attribute, in all releases <= 7.1. This was caused
by a bug in the code that creates pg_attribute rows for multi-key
indexes: it put the same OID on each such row. This is fixed in current
sources, but it's graphic proof that nonunique OIDs don't hurt when
they're not being used for lookup...
> On Tue, Jul 10, 2001 at 10:58:41PM -0700, Joe Conway wrote: > > > You'll need to do an initdb after this (I think) because it adds a new > > > internal function. I used OID 1716, I hope nobody is using that one right > > > now. > > > > > > > I asked this one myself not too long ago :-) > > > > There's a shell script: > > ~/pgsql/src/include/catalog/unused_oids > > Thanks. I did use the script and it says it's free. But maybe someone else > has a patch somewhere else right now wnho is using it. The only way we'll > find out is if they both get added and somebody notices. > > Does somewhere check for duplicate oids? Yes, I usually check that when I do a patch that adds OID's, or at least I should. :-) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026