Gregory Stark <[EMAIL PROTECTED]> writes:
> We're talking about code which is recompiled for a new version of
> Postgres but not altered to return the recheck flag for every tuple?
> Can we rig the code so it effectively returns recheck=true all the
> time in that case?
That's what we've got now.
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>> Anybody else have an opinion?
>
> Better slow than wrong in this case.
>
> The "better to break obviously than subtly" argument doesn't hold here,
> because
> "slow" isn't the same as broken, and returning extra incorrect rows isn't
> "obviously
Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
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
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> 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 shou
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
I've committed the runtime-recheck changes. Oleg had mentioned that
GIST text search could be improved by using runtime rechecking, but
I'll leave any refinements of that sort up to you.
One thing I was wondering about is that GIN and GIST are set up to
preinitialize the recheck flag to TRUE; thi
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> If we do this, should we remove RECHECK from the CREATE OPERATOR CLASS
>> syntax altogether, or leave it in but treat it as a no-op (probably
>> with a warning)?
> I think, it should be a error, but not a syntax error - hint should point to
> use
>
I've committed changes that move the determination of whether recheck is
required into the index AMs. Right now, GIST and GIN just always set
the recheck flag to TRUE. Obviously that control should be pushed down
to the opclass consistent() functions, but I don't know that code well
enough to be
> I'm leaning towards removing RECHECK because it'll allow simplification
I vote to do it.
> I seem to recall that you had some plans for other incompatible changes
> in the call conventions for GIST/GIN support functions, too. If
Right now we suggest only new feature which just extent interface.
On Fri, Apr 11, 2008 at 9:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> To be blunt, that seems like a really bad idea, and I have not the
> slightest hesitation about breaking your ability to do it. How
> do you know that the recheck-need corresponds to what you are testing
> on the applicatio
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> Just wanted to point out that I personnally use the capability to
> remove the RECHECK of PostGIS opclass (I define a similar opclass
> without the recheck) when I enforce the SRID in the application:
To be blunt, that seems like a really bad idea, an
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Now we choose - save compatibility or not.
> We can save flag RECHECK and introduce optional needRecheck argument for
> consistent function and new opclass can use new interface, old ones will work
> with RECHECK. Or we remove RECHECK and force opclasse
On Fri, Apr 11, 2008 at 7:41 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Offhand I suspect
> only the PostGIS project would be affected.
Just wanted to point out that I personnally use the capability to
remove the RECHECK of PostGIS opclass (I define a similar opclass
without the recheck) when I e
Don't we need to change the GiST/GIN support function interface anyway,
to be able to return the "recheck" flag?
Now we choose - save compatibility or not.
We can save flag RECHECK and introduce optional needRecheck argument for
consistent function and new opclass can use new interface, old one
I can think of is that it'd break user-defined opclasses ... but it's
not like we don't change the API for GIST/GIN support functions from
time to time anyway. Does anyone have any idea how many people are
Hmm. The biggest breakage of interface to indexes was a removing
pg_am.amconcurrent flag -
Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
RECHECK flag could be removed.
Hmm, that's slightly more radical than I was considering, but it would
simplify matters wouldn't it? The only strong argument against it that
I can think of is that it'd break user-defined opclasses ... b
[ Changing subject to draw people's attention ... ]
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> RECHECK flag could be removed.
Hmm, that's slightly more radical than I was considering, but it would
simplify matters wouldn't it? The only strong argument against it that
I can think of is that it'd
17 matches
Mail list logo
