> 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: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
