[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/
Show quoted text
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/
Show quoted text
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_oidsThanks. 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