Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> 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
>>> memory serves).
>
>> 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
>> every tuple.
>
> 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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com