Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This will not work, unless we change the planner --- the original quals
aren't necessarily there in some corner cases (partial indexes, if
This is only for bitmap scans, which *do* always have the original quals
available in the executor (BitmapHeapScanState.bitmapqualorig).
That's because we have to recheck the original conditions when the
bitmap goes lossy.
Yeah, but the index AM has to support regular indexscans too, and those
are not prepared for runtime lossiness determination; nor am I
particularly willing to add that.
Well, do you have an alternative suggestion?
With the unapplied GIT patch, the index doesn't store the index key of
I thought the design was to eliminate *duplicate* keys from the index.
Not to lose data.
The idea *isn't* to deal efficiently with duplicate keys. The bitmap
indexam is better suited for that.
The idea really is to lose information from the leaf index pages, in
favor of a drastically smaller index. On a completely clustered table,
the heap effectively is the leaf level of the index.
I'm glad we're having this conversation now. I'd really appreciate
review of the design. I've been posting updates every now and then,
asking for comments, but never got any. If you have suggestions, I'm all
ears and I still have some time left before feature freeze to make changes.
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings