From: | Ofer Israeli <oferi(at)checkpoint(dot)com> |
---|---|
To: | Frank Lanitz <frank(at)frank(dot)uvena(dot)de> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Inserts or Updates |
Date: | 2012-02-12 18:32:11 |
Message-ID: | 217DDBC2BB1E394CA9E7446337CBDEF20102C056C2A6@il-ex01.ad.checkpoint.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Frank Lanitz wrote:
> Am 12.02.2012 11:48, schrieb Ofer Israeli:
>> Frank Lanitz wrote:
>>>> Am 07.02.2012 18:40, schrieb Ofer Israeli:
>>>>>> Table 1: 46 columns 23 indexes on fields of the following
>>>>>> types: INTEGER - 7 TIMESTAMP - 2 VARCHAR - 12 UUID - 2
>>>>>>
>>>>>> 23 columns 12 indexes on fields of the following types:
>>>>>> INTEGER - 3 TIMESTAMP - 1 VARCHAR - 6 UUID - 2
>>>>
>>>> Are you regularly updating all columns? If not, maybe a good idea
>>>> to split the tables so highly updated columns don't effect complete
>>>> line.
>> We're not always updating all of the columns, but the reason for
>> consolidating all the columns into one table is for UI purposes - in
>> the past, they had done benchmarks and found the JOINs to be
>> extremely slow and so all data was consolidated into one table.
>
> Ah... I see. Maybe you can check whether all of the data are really
> needed to fetch with one select but this might end up in tooo much
> guessing and based on your feedback you already did this step.
This was indeed checked, but I'm not sure it was thorough enough so we're having a go at it again. In the meanwhile, the autovacuum configurations have proved to help us immensely so for now we're good (will probably be asking around soon when we hit our next bottleneck :)). Thanks for your help!
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2012-02-12 19:49:33 | Re: random_page_cost = 2.0 on Heroku Postgres |
Previous Message | Frank Lanitz | 2012-02-12 18:29:13 | Re: Inserts or Updates |