On Tue, Aug 01, 2006 at 02:26:18PM -0700, [EMAIL PROTECTED] wrote:
> Kenneth Marshall wrote:
> > On Fri, Jul 28, 2006 at 12:14:49PM -0500, Jim C. Nasby wrote:
> > > On Thu, Jul 27, 2006 at 01:46:01PM -0400, Alvaro Herrera wrote:
> > > > Jim Nasby wrote:
> > > > > On Jul 25, 2006, at 3:31 PM, Tom La
Kenneth Marshall wrote:
> On Fri, Jul 28, 2006 at 12:14:49PM -0500, Jim C. Nasby wrote:
> > On Thu, Jul 27, 2006 at 01:46:01PM -0400, Alvaro Herrera wrote:
> > > Jim Nasby wrote:
> > > > On Jul 25, 2006, at 3:31 PM, Tom Lane wrote:
> > > > >Hannu Krosing <[EMAIL PROTECTED]> writes:
> > >
> > > > >>
On Tue, 2006-08-01 at 07:55 -0700, Luke Lonergan wrote:
> WRT hashing - we use FNV hash which is a very nice, very fast modern hash
> algorithm. We would contribute that if we worked on this.
We currently use Bob Jenkins' hash function[1], which is apparently
faster than FNV on most architectures
Jim,
On 7/28/06 12:27 PM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> In that case, perhaps this is something Greenplum might be interested
> in, since it might fit nicely between bitmap and btree indexes.
I'm certainly following the thread.
We have talked about hash and btree organized tables
Tom Lane <[EMAIL PROTECTED]> writes:
> I think the problem may well be that we use hash buckets that are too
> large (ie, whole pages). After we fetch the page, we have to grovel
> through every tuple on it to find the one(s) that really match the
> query, whereas btree has a much more intellige
On Fri, Jul 28, 2006 at 12:14:49PM -0500, Jim C. Nasby wrote:
> On Thu, Jul 27, 2006 at 01:46:01PM -0400, Alvaro Herrera wrote:
> > Jim Nasby wrote:
> > > On Jul 25, 2006, at 3:31 PM, Tom Lane wrote:
> > > >Hannu Krosing <[EMAIL PROTECTED]> writes:
> >
> > > >>What would be the use-case for hash i
On Fri, Jul 28, 2006 at 03:14:33PM -0400, Alvaro Herrera wrote:
> Jim C. Nasby wrote:
>
> > What I'm getting at is that I've never seen any explanation for the
> > theoretical use cases where a hash index would outperform a btree. If we
> > knew what kind of problems hash indexes were supposed to
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The btree index needs to descend potentially many pages before getting
> to the leaf page, where the actual index is stored. The hash index can
> get at the "leaf" node in --supposedly-- one fetch. Btree is O(logN) to
> get a single key, while hash is
Jim C. Nasby wrote:
> What I'm getting at is that I've never seen any explanation for the
> theoretical use cases where a hash index would outperform a btree. If we
> knew what kind of problems hash indexes were supposed to solve, we could
> try and interest people who are solving those kinds of p
On Thu, Jul 27, 2006 at 01:46:01PM -0400, Alvaro Herrera wrote:
> Jim Nasby wrote:
> > On Jul 25, 2006, at 3:31 PM, Tom Lane wrote:
> > >Hannu Krosing <[EMAIL PROTECTED]> writes:
>
> > >>What would be the use-case for hash indexes ? And what should be
> > >>done to make them faster than btree ?
>
Jim Nasby wrote:
> On Jul 25, 2006, at 3:31 PM, Tom Lane wrote:
> >Hannu Krosing <[EMAIL PROTECTED]> writes:
> >>What would be the use-case for hash indexes ? And what should be
> >>done to make them faster than btree ?
> >
> >If we knew, we'd do it ;-) But no one's put enough effort into it
> >t
11 matches
Mail list logo
