On 9/10/2007 11:06 AM, 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)

How can Slony know that none of those column might have a default value 
different from the value explicitly given *on any subscriber out there*?

> 
> 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 :-(

Feel free to provide a patch that implements an optional, runtime 
configurable optimization to suppress columns that are NULL on INSERT.


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 #