From: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: GIN improvements part 1: additional information |
Date: | 2013-10-11 21:55:19 |
Message-ID: | 525873C7.3070402@fuzzy.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10.10.2013 13:57, Heikki Linnakangas wrote:
> On 09.10.2013 02:04, Tomas Vondra wrote:
>> On 8.10.2013 21:59, Heikki Linnakangas wrote:
>>> On 08.10.2013 17:47, Alexander Korotkov wrote:
>>>> Hi, Tomas!
>>>>
>>>> On Sun, Oct 6, 2013 at 3:58 AM, Tomas Vondra<tv(at)fuzzy(dot)cz> wrote:
>>>>
>>>>> I've attempted to rerun the benchmarks tests I did a few weeks ago,
>>>>> but
>>>>> I got repeated crashes when loading the data (into a table with
>>>>> tsvector+gin index).
>>>>>
>>>>> Right before a crash, theres this message in the log:
>>>>>
>>>>> PANIC: not enough space in leaf page!
>>>>>
>>>>
>>>> Thanks for testing. Heikki's version of patch don't works for me too on
>>>> even much more simplier examples. I can try to get it working if he
>>>> answer
>>>> my question about GinDataLeafPageGetPostingList* macros.
>>>
>>> The new macros in that patch version were quite botched. Here's a new
>>> attempt.
>>
>> Nope, still the same errors :-(
>>
>> PANIC: not enough space in leaf page!
>> LOG: server process (PID 29722) was terminated by signal 6: Aborted
>> DETAIL: Failed process was running: autovacuum: ANALYZE public.messages
>
> I've continued hacking away at the patch, here's yet another version.
> I've done a lot of cleanup and refactoring to make the code more
> readable (I hope). I'm not sure what caused the panic you saw, but it's
> probably fixed now. Let me know if not.
Yup, this version fixed the issues. I haven't been able to do any
benchmarks yet, all I have is some basic stats
| HEAD | patched
======================================
load duration | 1084 s | 1086 s
subject index | 96 MB | 96 MB
body index | 2349 MB | 2051 MB
So there's virtually no difference in speed (which is expected, AFAIK)
and the large index on full message bodies is significantly smaller.
regards
Tomas
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2013-10-11 22:39:51 | Re: Auto-tuning work_mem and maintenance_work_mem |
Previous Message | Kevin Grittner | 2013-10-11 21:43:57 | Re: drop-index-concurrently-1 on master fails at serializable |