Horton

Re: Minmax indexes

Erik Rijkers <er@xs4all.nl>

View thread View on postgr.es
From: "Erik Rijkers" <er@xs4all.nl>
To: "Alvaro Herrera" <alvherre@2ndquadrant.com>
Cc: "Pg Hackers" <pgsql-hackers@postgresql.org>
Date: 2013-09-25T22:34:43Z
Lists: pgsql-hackers

Attachments

On Wed, September 25, 2013 22:34, Alvaro Herrera wrote:

> [minmax-5.patch]

I have the impression it's not quite working correctly.

The attached program returns different results for different values of enable_bitmapscan (consistently).

( Btw, I had to make the max_locks_per_transaction higher for even not-so-large tables -- is that expected?  For a 100M row
table, max_locks_per_transaction=1024 was not enough; I set it to 2048.  Might be worth some documentation, eventually. )

From eyeballing the results it looks like the minmax result (i.e. the result set with enable_bitmapscan = 1) yields only
the last part because the only 'last' rows seem to be present (see the values in column i in table tmm in the attached
program).


Thanks,

Erikjan Rijkers

Commits

  1. Refactor per-page logic common to all redo routines to a new function.

  2. Reduce use of heavyweight locking inside hash AM.

  3. Scan the buffer pool just once, not once per fork, during relation drop.

  4. Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>