[EMAIL PROTECTED] (Nathan Myers) writes:
> Seriously, "indislossy" is a singularly poor name for a predicate.
Perhaps, but it fits with the existing naming conventions for Postgres
catalog columns. Unless we want to indulge in wholesale renaming of
the system's catalog columns (and break an awfu
On Tue, Jul 10, 2001 at 01:36:33PM -0400, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > But why is this called lossy? Shouldn't it be called "exceedy"?
>
> Good point ;-). "lossy" does sound like the index might "lose" tuples,
> which is exactly what it's not allowed to do;
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> But why is this called lossy? Shouldn't it be called "exceedy"?
Good point ;-). "lossy" does sound like the index might "lose" tuples,
which is exactly what it's not allowed to do; it must find all the
tuples that match the query.
The terminology
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > But why is this called lossy? Shouldn't it be called "exceedy"?
>
> Good point ;-). "lossy" does sound like the index might "lose" tuples,
> which is exactly what it's not allowed to do; it must find all the
> tuples that match the query.
>
>
>
> > > > > > > > Can someone tell me what we use indislossy for?
> > > > >
> > > > > Ok, so the interpretation of this field is:
> > > > > A match in the index needs to be reevaluated in the heap tuple data,
> > > > > since a match in the index does not necessarily mean, that the hea
Tom Lane writes:
> Not true at all. The tuple commit status needs to be rechecked, yes,
> but with a normal index it is not necessary to recheck whether the index
> key field actually satisfies the index qual conditions. With a lossy
> index it *is* necessary to recheck --- the index may return
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
> A match in the index needs to be reevaluated in the heap tuple data,
> since a match in the index does not necessarily mean, that the heap tuple
> matches.
> AFAIK, this is true for all indexes in PostgreSQL, because index row
> Bruce Momjian writes:
>
> > > > > > Can someone tell me what we use indislossy for?
> > >
> > > Ok, so the interpretation of this field is:
> > > A match in the index needs to be reevaluated in the heap tuple data,
> > > since a match in the index does not necessarily mean, that the heap tu
> > > > > > > Can someone tell me what we use indislossy for?
> > > >
> > > > Ok, so the interpretation of this field is:
> > > > A match in the index needs to be reevaluated in the heap tuple data,
> > > > since a match in the index does not necessarily mean, that the heap
>tupl
Bruce Momjian writes:
> > > > > Can someone tell me what we use indislossy for?
> >
> > Ok, so the interpretation of this field is:
> > A match in the index needs to be reevaluated in the heap tuple data,
> > since a match in the index does not necessarily mean, that the heap tuple
> >
Added to pg_index.h file as a comment.
>
> > > > Can someone tell me what we use indislossy for?
>
> Ok, so the interpretation of this field is:
> A match in the index needs to be reevaluated in the heap tuple data,
> since a match in the index does not necessarily mean, that the
> > > Can someone tell me what we use indislossy for?
Ok, so the interpretation of this field is:
A match in the index needs to be reevaluated in the heap tuple data,
since a match in the index does not necessarily mean, that the heap tuple
matches.
If the heap t
> One problem with keeping it is that interface coders are getting
> confused by some of the unused system table columns, assuming they mean
> something, when in fact they don't. Both ODBC and JDBC have had this
> problem that I fixed today.
Imho the correct answer to this would be to implement
> > Let's avoid removing things for the sake of removing them ... might be an
> > old idea that, if someone takes the time to research, might prove useful
> > ...
>
> Yea, there is actually some code attached to this vs. the others that
> had no code at all. Are we ever going to do partial inde
14 matches
Mail list logo
