| Lists: | pgsql-patches |
|---|
| From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | "Teodor Sigaev" <teodor(at)sigaev(dot)ru> |
| Cc: | "Patches" <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Yet more tsearch refactoring |
| Date: | 2007-09-10 16:27:46 |
| Message-ID: | 46E57082.3060406@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-patches |
* Defined new struct WordEntryPosVector that holds a uint16 length and a
variable size array of WordEntries. This replaces the previous
convention of a variable size uint16 array, with the first element
implying the length. WordEntryPosVector has the same layout in memory,
but is more readable in source code. The POSDATAPTR and POSDATALEN
macros are still used, though it would now be more readable to access
the fields in WordEntryPosVector directly.
* Removed needfree field from DocRepresentation. It was always set to false.
* Miscellaneous other commenting and refactoring
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| Attachment | Content-Type | Size |
|---|---|---|
| tsearch-refactor-3.patch | text/x-diff | 16.0 KB |
| From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
| Cc: | Patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: Yet more tsearch refactoring |
| Date: | 2007-09-10 20:54:54 |
| Message-ID: | 46E5AF1E.3090301@sigaev.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-patches |
Heikki Linnakangas wrote:
> * Defined new struct WordEntryPosVector that holds a uint16 length and a
> variable size array of WordEntries. This replaces the previous
> convention of a variable size uint16 array, with the first element
> implying the length. WordEntryPosVector has the same layout in memory,
> but is more readable in source code. The POSDATAPTR and POSDATALEN
> macros are still used, though it would now be more readable to access
> the fields in WordEntryPosVector directly.
Did you check it on 64-bit boxes with strict alignment? I remember that was a
headache for me.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
| From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | "Teodor Sigaev" <teodor(at)sigaev(dot)ru> |
| Cc: | "Patches" <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: Yet more tsearch refactoring |
| Date: | 2007-09-10 21:59:44 |
| Message-ID: | 46E5BE50.70803@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-patches |
Teodor Sigaev wrote:
> Heikki Linnakangas wrote:
>> * Defined new struct WordEntryPosVector that holds a uint16 length and a
>> variable size array of WordEntries. This replaces the previous
>> convention of a variable size uint16 array, with the first element
>> implying the length. WordEntryPosVector has the same layout in memory,
>> but is more readable in source code. The POSDATAPTR and POSDATALEN
>> macros are still used, though it would now be more readable to access
>> the fields in WordEntryPosVector directly.
>
> Did you check it on 64-bit boxes with strict alignment? I remember that
> was a headache for me.
No, I didn't. But I don't see how it would make a difference, the
resulting memory layout is the same AFAICS.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Teodor Sigaev" <teodor(at)sigaev(dot)ru> |
| Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Patches" <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: Yet more tsearch refactoring |
| Date: | 2007-09-11 09:30:28 |
| Message-ID: | 87k5qxzgzv.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-patches |
"Teodor Sigaev" <teodor(at)sigaev(dot)ru> writes:
> Did you check it on 64-bit boxes with strict alignment? I remember that was a
> headache for me.
Is there a regression test which would fail if this kind of problem crops up?
Not every developer can test every type of hardware but (aside from believing
the code will work of course) we should at a minimum be certain that the build
farm will detect the problem.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com