On Fri, Jul 18, 2008 at 1:00 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > While we are griping about readability: failure to update the comments > to match the code is NOT, NOT, NOT acceptable. I had barely started > to read the patch before encountering this insult to the reader: > ...
As this is Xiao's first patch to the community, I'd appreciate it if you guys would chill a little. I'm fully aware of what needs to be done with it clean-up wise, but given that we're under some time constraints, I asked that he submit his preliminary patch for those who wanted to preview/test it. Again, this patch is nowhere near acceptance quality, nor was it intended to be. I'll make sure he gets the next one cleaned up prior to submitting it. The real question now has been listed above; why are hash index queries, including this patch, no better than b-tree even for straight equality comparisons? Because hash is lossy, we could easily be performing multiple I/Os for recheck, and that may be causing some of the performance problems. I haven't checked I/O for that yet, but was wondering if you (Tom) knew of any major design/implementation deficiency we should be taking into consideration regarding PG's hash index implementation? -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 499 Thornall Street, 2nd Floor | [EMAIL PROTECTED] Edison, NJ 08837 | http://www.enterprisedb.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
