From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Rob Sargent <robjsargent(at)gmail(dot)com> |
Cc: | Brian Hirt <bhirt(at)me(dot)com>, Dmitriy Igrishin <dmitigr(at)gmail(dot)com>, Viktor Nagy <viktor(dot)nagy(at)toolpart(dot)hu>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Values larger than 1/3 of a buffer page cannot be indexed. |
Date: | 2011-03-14 13:25:03 |
Message-ID: | AANLkTikqL-13Bz-_WurkxnWFC5MDBraOt4v2vztY9wzk@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Mar 13, 2011 at 4:37 PM, Rob Sargent <robjsargent(at)gmail(dot)com> wrote:
>
>
> Brian Hirt wrote:
>>
>> On Mar 13, 2011, at 12:05 PM, Dmitriy Igrishin wrote:
>>
>>> Hey Viktor,
>>>
>>> 2011/3/13 Viktor Nagy <viktor(dot)nagy(at)toolpart(dot)hu
>>> <mailto:viktor(dot)nagy(at)toolpart(dot)hu>>
>>>
>>> hi,
>>>
>>> when trying to insert a long-long value, I get the following error:
>>>
>>> index row size 3120 exceeds maximum 2712 for index
>>> "ir_translation_ltns"
>>> HINT: Values larger than 1/3 of a buffer page cannot be indexed.
>>> Consider a function index of an MD5 hash of the value, or use
>>> full text indexing.
>>>
>>> is there a way to generate this recommended function index of an
>>> md5 hash on an already existing database and tables (filled with
>>> data)?
>>>
>>> Just create index this way, e.g.
>>> CREATE INDEX ir_translation_ltns ON tab ((md5(col)));
>>> where "tab" and "col" are table and column of which you want
>>> to create btree index.
>>
>> This probably goes without saying, but you'll have to use col =
>> md5('blahblahblahblah') in your qualifiers to get the benefit of the index.
>>
>> --brian
>
> Unless the point is to guarantee uniqueness of the "long-long value"s.
md5 will do that too: the main thing you lose going to hash indexing
is ordering.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Igor Neyman | 2011-03-14 14:00:09 | Re: How do you change the size of the WAL files? |
Previous Message | Hannes Erven | 2011-03-14 13:15:51 | Re: Postgres 8.3 vs. 8.4 - Query plans and performance |