On Thu, 2006-11-16 at 17:48 -0500, Tom Lane wrote:
AFAICS, any hash index exceeding a single segment is at serious risk.
The fact that we've not heard gripes before suggests that no one is
using gigabyte-sized hash indexes.
Seems so.
But it seems mighty late in the beta cycle to be making
On Fri, 2006-11-17 at 08:26 -0600, Kenneth Marshall wrote:
I certainly hold out some hope that they can improved. I would like to see
them still included. Once they are gone, it will be much harder to ever
add them back.
OK, you got it - keep hash indexes then.
--
Simon Riggs
Simon Riggs [EMAIL PROTECTED] writes:
Do we think there is hope of improving hash indexes?
Sure. They lack WAL support, which is just a small matter of
programming. And no one has ever spent any time on performance
optimization for them, but it certainly seems like there ought to be
scope for
Simon Riggs wrote:
Do we think there is hope of improving hash indexes?
I thought about this a bit. I have an idea that the hash index might
have the fixed number of buckets specified in create index statement and
the tuples in each of these buckets should be stored in a b-tree. This
should
me wrote:
i've loaded 1gb of data without any xlog-problems, whereas with the 8.2b2
executable it locked up after ~100mb. the xlog-files are cycling...
if i need to test for some specific behaviour let me know.
what's the status on this patch for inclusion in future 8.2 builds? would be
