From: | Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> |
---|---|
To: | Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | gsoc, oprrest function for text search take 2 |
Date: | 2008-07-28 11:34:16 |
Message-ID: | 488DAEB8.3000402@students.mimuw.edu.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I know Commit Fest is in progress, as well as the holiday season. But
the Summer of Code ends in about three weeks, so I'd like to request a
bit of out-of-order processing :)
My previous mail sent to -hackers is here:
http://archives.postgresql.org/message-id/4881CCCF.4020905@students.mimuw.edu.pl
I had problems applying the patch from that mail (it got mangled
somehow, could by my mail agent...), so I'm attaching it again.
There are two things that I'm not particularly proud of in the patch.
First is palloc()ing and filling in a table simply to user qsort() on
it. I guess I could either hack up a version of get_attstatsslot() that
returns an array of (element, frequency) pairs or sort the elements by
hand instead of using qsort() and keep the order of frequencies in sync
while doing the sort.
Another thing are cstring_to_text_with_len calls. I'm doing them so I
can use bttextcmp in bsearch(). I think I could come up with a dedicated
function to return text Datums and WordEntries (read: non-NULL
terminated strings with a given length).
Are these unsignificant? Or should I do these optimizations? Or, sadly,
signs that using binary search is not a good decision?
Thanks,
Jan
--
Jan Urbanski
GPG key ID: E583D7D2
ouden estin
Attachment | Content-Type | Size |
---|---|---|
tssel-gsoc08-tss.patch | text/plain | 11.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-07-28 11:49:57 | Re: issues/experience with building postgres on Windows |
Previous Message | Zdenek Kotala | 2008-07-28 11:32:54 | Re: Review: DTrace probes (merged version) ver_03 |