Heikki Linnakangas writes:
> Ah, that opens the door to do something I considered earlier but
> rejected because of alignment: instead of three 32-bit word fetches, we
> could fetch one 64-bit word and 32-bit word. Might shave a few more
> cycles...
Hm ... I suspect that might be a small win o
On 02.07.2011 21:07, Tom Lane wrote:
I wrote:
I tweaked the patch a bit further (don't pessimize the boundary case
where there's exactly 4n+1 trigrams, avoid forcing trg1 into memory,
improve the comment) and attach that version below. This is a little
bit faster but I still wonder if it's wort
I wrote:
> I tweaked the patch a bit further (don't pessimize the boundary case
> where there's exactly 4n+1 trigrams, avoid forcing trg1 into memory,
> improve the comment) and attach that version below. This is a little
> bit faster but I still wonder if it's worth the price of adding an
> obscu
Heikki Linnakangas writes:
> I couldn't resist looking into this, and came up with the attached
> patch. I tested this with:
> CREATE TABLE words (word text);
> COPY words FROM '/usr/share/dict/words';
> CREATE INDEX i_words ON words USING gist (word gist_trgm_ops);
> And then ran "REINDEX INDE
On Fri, Jun 24, 2011 at 3:01 PM, Heikki Linnakangas
wrote:
> On 24.06.2011 21:24, Robert Haas wrote:
>>
>> Out of curiosity (and because there is no comment or Assert here), how
>> can you be so sure of the input alignment?
>
> The input TRGM to makesign() is a varlena, so it must be at least 4-by
On 24.06.2011 21:24, Robert Haas wrote:
Out of curiosity (and because there is no comment or Assert here), how
can you be so sure of the input alignment?
The input TRGM to makesign() is a varlena, so it must be at least 4-byte
aligned. If it was not for some reason, the existing VARSIZE invoca
On Fri, Jun 24, 2011 at 12:51 PM, Heikki Linnakangas
wrote:
> On 24.06.2011 11:40, Heikki Linnakangas wrote:
>>
>> On 21.06.2011 13:08, Alexander Korotkov wrote:
>>>
>>> I believe it's due to relatively expensive penalty
>>> method in that opclass.
>>
>> Hmm, I wonder if it could be optimized. I d
On 24.06.2011 11:40, Heikki Linnakangas wrote:
On 21.06.2011 13:08, Alexander Korotkov wrote:
I believe it's due to relatively expensive penalty
method in that opclass.
Hmm, I wonder if it could be optimized. I did a quick test, creating a
gist_trgm_ops index on a list of English words from
/u
