On 9/10/2007 12:40 PM, Christopher Browne wrote:
> Cyril SCETBON wrote:
>>
>>
>> Jan Wieck wrote:
>>> On 9/10/2007 10:07 AM, Cyril SCETBON wrote:
>>>> Hi,
>>>>
>>>> We're hitting 400 requests per second and noticed that sl_log_? are 
>>>> growing a lot. This is also due to the fact that our tables have a 
>>>> lot of columns (more that 100). We noticed that slony stores each 
>>>> column and its value for each request in sl_log_x. Would it not be 
>>>> more optimized to store just the user request ? Actually, a user is 
>>>> just updating a few column, or inserting a tuple by giving some 
>>>> attributes but not all, however as slony stores every column with 
>>>> its value it sl_log_x, these tables are growing very fast :-(
>>>
>>> Slony only logs columns where the value actually has changed. Please 
>>> explain in detail how you propose that the log table would contain 
>>> which columns have changed without naming them.
>> when I execute this command on the master :
>>
>> insert into t1(ise) values('cyril100001');
>>
>> I can see in sl_log_1 :
>>
>> psql>select log_cmddata from sl_log_1;
>> (ise,id,id2) values ('cyril100001','24161',NULL)
>>
>> dbtest=# \d t1;
>>                                Table "public.t1"
>> Column |         Type          |                    
>> Modifiers                   
>> --------+-----------------------+------------------------------------------------- 
>>
>> ise    | character varying(54) | not null
>> id     | integer               | not null default 
>> nextval('t1_id_seq'::regclass)
>> id2    | integer               |
>> Indexes:
>>    "t1_pkey" PRIMARY KEY, btree (ise)
>> Triggers:
>>    "_CLUSTER1_logtrigger_1" AFTER INSERT OR DELETE OR UPDATE ON t1 FOR 
>> EACH ROW EXECUTE PROCEDURE "_CLUSTER1".logtrigger('_CLUSTER1', '1', 
>> 'kvv')
>>
>> I agree for id which is an auto_increment but not for id2 :-(
>>
>> In another plateform my table has more than  100 columns as said 
>> earlier and that's really matter :-(
> Jan's request seems to remain perfectly good...
> 
> "Please explain in detail how you propose that the log table would 
> contain which columns have changed without naming them."
> 
> It is *not* obvious how to avoid naming all of the columns.  It is not 
> safe to simply assume "that column was null so we may omit it" - 
> different nodes may be configured differently, and it may well be 
> important to actually have that NULL value.

Neither would it be safe to assume all subscribers actually have all 
tables with the exact identical column order. One might have been 
created with a newer version of the schema, while another one was 
upgraded with ALTER TABLE ADD COLUMN.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #