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
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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to