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.