Christopher Browne wrote:

>The thought is to store record size in a new field on sl_log_1, call
>it "log_cmdsize", and populate it at insert time.
>  
>
May not need to store it; I would expect that the size of a text field
could be determined cheaply (Jan would know - he wrote toast).

>We declare LOG cursor as being ...
>
>declare LOG cursor for select log_origin, log_xid, log_tableid, 
>       log_actionseq, log_cmdtype, log_cmdsize
>from sl_log_1 [with various other criteria] order by log_actionseq;
>  
>
...etc. Looks good to me, *except*, my reading of remote_worker.c made
me believe it would loop retrieving 100 rows repeatedly, while another
thread sends to the replicated db. If I am right, we would still need
some way of pausing the 'pull' part of the pull->push mechanism. Or I
misread the code -- having just looked at it again, it may only read 100
at a time.

You may even be able to refine this (depending on cost of such things)
by selecting substring(log_cmddata from 1 for 1024) so that small
commands require no extra IO.

>The mechanism for efficiently pulling the detail data from sl_log_1
>based on a set of keys probably requires generating a 2D array of
>index values to pass in to a set-returning stored procedure.
>  
>
You may find that reiterating the cursor is simplest, especially if we
have length stored: you can select where log_cmdlength>1024.

>1.  Set the FETCH value(s) to 1 rather than 100 at compile time if you
>know you have problems with Fat Rows.
>  
>
See above. I have not tried recompiling with a value of 1, but I thought
it would just loop. Maybe I misread the code.

>2.  We have to do something quite a bit cleverer, probably similar to
>what I outlined, if we don't want to injure users that don't use Fat
>Rows.
>  
>
If we don't need to change the schema (eg. if length(log_cmddata) is
cheap) then would 1.1 be possible?


Thanks for the continuing help.