2. If we set the flag TRUE, and that's wrong (ie, the query is really
exact) then a useless recheck occurs when we arrive at the heap.
Nothing visibly goes wrong, but the query is slower than it should be.
4. If we set the flag FALSE, and that's wrong (ie, the query is really
inexact), then rows that don't match the query may get returned.
By the argument that it's better to break things obviously than to
break them subtly, risking case 4 seems more attractive than risking
case 2.
The single thought is: usually, it's very hard to see that query returns more
results that it should be. It doesn't matter for fulltext search (and it has
very good chance to stay unnoticed forever because wrong rows will be sorted
down by ranking function, although performance will decrease. But text search is
now built-in :-) ), but for other modules it may be critical, especially when
content of db depends on result of such query.
It seems to me, there was the bug in btree at one time - it doesn't keep
uniqueness and some values was duplicated. User noticed that only during
restoring of db.
What this means is that, if we make the preinitialization value FALSE,
then an existing GIST/GIN opclass that doesn't use RECHECK will load
just fine into 8.4 and everything will work as expected, even without
touching the C code.
Yes.
An opclass that does use RECHECK will fail to
load from the dump, and if you're stubborn and edit the dump instead
of getting a newer version of the module, you'll start getting wrong
query answers. This means that all the pain is concentrated on the
RECHECK-using case. And you can hardly maintain that you weren't
I don't think that restoration of dump from old versions with modules is good
practice anyway and saved RECHECK will signal about problem earlier.
If user edits dump to remove RECHECK flag then he is an enemy to himself.
So I'm thinking it might be better to switch to the other
preinitialization setting. Comments?
Agreed.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
