On Wed, May 30, 2012 at 12:21:33AM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, May 29, 2012 at 11:21 PM, Jeff Janes jeff.ja...@gmail.com wrote:
2) Only support bitmap scans and not ordinary tid scans (the way gin
indexes already do).
-1 on losing amgettuple.
On 30 May 2012 04:54, Robert Haas robertmh...@gmail.com wrote:
This was a hobby horse of mine a couple of years ago, but I never got
much traction. The main question I have is, what do we even want hash
indexes to be? NBTree is very good, has been extensively optimized,
and extensively
On Wed, May 30, 2012 at 3:49 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 30 May 2012 04:54, Robert Haas robertmh...@gmail.com wrote:
This was a hobby horse of mine a couple of years ago, but I never got
much traction. The main question I have is, what do we even want hash
indexes to be?
I ran a SELECT-only pgbench test today on the IBM POWER7 box with 64
concurrent clients and got roughly 305,000 tps. Then, I created a
hash index on pgbench_accounts (aid), dropped the primary key, and
reran the test. I got roughly 104,000 tps. 'perf -g -e cs' suggested
lock contention in
On Tue, May 29, 2012 at 5:19 PM, Robert Haas robertmh...@gmail.com wrote:
I ran a SELECT-only pgbench test today on the IBM POWER7 box with 64
concurrent clients and got roughly 305,000 tps. Then, I created a
hash index on pgbench_accounts (aid), dropped the primary key, and
reran the test.
On Tue, May 29, 2012 at 11:21 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, May 29, 2012 at 5:19 PM, Robert Haas robertmh...@gmail.com wrote:
I ran a SELECT-only pgbench test today on the IBM POWER7 box with 64
concurrent clients and got roughly 305,000 tps. Then, I created a
hash index
Robert Haas robertmh...@gmail.com writes:
On Tue, May 29, 2012 at 11:21 PM, Jeff Janes jeff.ja...@gmail.com wrote:
2) Only support bitmap scans and not ordinary tid scans (the way gin
indexes already do).
-1 on losing amgettuple. I regret that we lost that for GIN and I
shall regret it more
