On Fri, Nov 01, 2013 at 01:31:10PM +, Dimitri Fontaine wrote:
Hi,
Here's an idea: when a user ask for an Hash Index transparently build a
BTree index over an hash function instead.
Advantages:
- it works
- it's crash safe
- it's (much?) faster than a hash index anyways
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Here's an idea: when a user ask for an Hash Index transparently build a
BTree index over an hash function instead.
-1. If someone asks for a hash index, they should get a hash index.
If you feel the documentation isn't sufficiently clear about
Tom Lane t...@sss.pgh.pa.us writes:
-1. If someone asks for a hash index, they should get a hash index.
If you feel the documentation isn't sufficiently clear about the problems
involved, we can work on that.
Fair enough.
Lastly: what real-world problem are we solving by kicking that code
On 11/01/2013 09:49 AM, Tom Lane wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Here's an idea: when a user ask for an Hash Index transparently build a
BTree index over an hash function instead.
-1. If someone asks for a hash index, they should get a hash index.
If you feel the
Andrew Dunstan and...@dunslane.net writes:
Yeah, and there's this: I've had at least one client who switched to
using hash indexes and got a significant benefit from it precisely
because they aren't WAL logged. They could afford to rebuild the indexes
in the unlikely event of a crash, but
On 2013-11-01 09:49:57 -0400, Tom Lane wrote:
Lastly: what real-world problem are we solving by kicking that code
to the curb?
It makes hashed lookups much easier to use. Currently if you want
indexed access over wide columns and equality is all you need you need
to write rather awkward queries
On Friday, November 1, 2013, k...@rice.edu wrote:
On Fri, Nov 01, 2013 at 01:31:10PM +, Dimitri Fontaine wrote:
Hi,
Here's an idea: when a user ask for an Hash Index transparently build a
BTree index over an hash function instead.
Advantages:
- it works
- it's crash
On Fri, Nov 1, 2013 at 6:31 AM, Dimitri Fontaine dimi...@2ndquadrant.frwrote:
Hi,
Here's an idea: when a user ask for an Hash Index transparently build a
BTree index over an hash function instead.
Could something be added to the planner so that you can just build a btree
index on a hash
On Fri, Nov 1, 2013 at 6:31 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Hi,
Here's an idea: when a user ask for an Hash Index transparently build a
BTree index over an hash function instead.
Advantages:
- it works
- it's crash safe
- it's (much?) faster than a hash index
On Fri, Nov 1, 2013 at 8:52 AM, Daniel Farina dan...@heroku.com wrote:
On Fri, Nov 1, 2013 at 6:31 AM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Also, talking with Peter Geoghegan, it's unclear that there's a use case
where a hash index would be faster than a btree index over the hash
On 11/01/2013 03:49 PM, Andres Freund wrote:
On 2013-11-01 09:49:57 -0400, Tom Lane wrote:
Lastly: what real-world problem are we solving by kicking that code
to the curb?
It makes hashed lookups much easier to use. Currently if you want
indexed access over wide columns and equality is all
On Fri, Nov 1, 2013 at 9:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The bigger picture here is that such an approach amounts to deciding that
no one will ever be allowed to fix hash indexes. I'm not for that, even
if I'm not volunteering to be the fixer myself.
Yeah.
I have thought about
12 matches
Mail list logo
