From: Tom Lane <tgl@sss.pgh.pa.us>
To: Zdenek Kotala <Zdenek.Kotala@Sun.COM>
Cc: Xiao Meng <mx.cogito@gmail.com>
Cc: pgsql-patches@postgresql.org, "Jonah H. Harris" <jonah.harris@gmail.com>
Subject: Re: hash index improving v3
Date: Thu, 04 Sep 2008 19:11:28 -0400
Message-ID: <7627.1220569888@sss.pgh.pa.us> (raw)
In-Reply-To: <29987.1220560114@sss.pgh.pa.us>
References: <ded849dd0808171846g2c6c65adub942bd2510a6c94f@mail.gmail.com>
<48BFDA8D.3080506@sun.com>
<29987.1220560114@sss.pgh.pa.us>
Here is an updated patch incorporating Zdenek's review, my own
observation that we should make the index tupledesc tell the truth,
and some other fixes/improvements such as making backwards scans
work as expected.
The main thing lacking before this could be committed, from a code
standpoint, is a cleaner solution to the problem of adjusting the
index tupledesc (see the ugly hack in catalog/index.c). However,
that complaint is irrelevant for functionality or performance testing,
so I'm throwing this back out there in hopes someone will do some...
I thought a little bit about how to extend this to store both hashcode
and original index key, and realized that the desire to have a truthful
index tupledesc makes that a *whole* lot harder. The planner, and
really even the pg_index catalog representation, assume that the visible
columns of an index are one-for-one with the index keys. We can slide
through with the attached patch because this is still true ---
effectively we're just using a "storage type" different from the indexed
column's type for hash indexes, as already works for GIST and GIN.
But having two visible columns would bollix up quite a lot of stuff.
So I think if we actually want to do that, we'd need to revert to the
concept of cheating on the tupledesc. Aside from the various uglinesses
that I was able to remove from the original patch by not having that,
I'm still quite concerned that we'd find something else wrong with
doing that, further down the road.
So my thinking right now is that we should just test this patch as-is.
If it doesn't show really horrid performance when there are lots of
hash key collisions, we should forget the store-both-things idea and
just go with this.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: tgl@sss.pgh.pa.us, Zdenek.Kotala@Sun.COM, mx.cogito@gmail.com, jonah.harris@gmail.com
Subject: Re: hash index improving v3
In-Reply-To: <7627.1220569888@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox