On 4/4/2006 4:06 PM, Miguel wrote:

> Andrew Sullivan wrote:
> 
>>On Tue, Apr 04, 2006 at 11:56:29AM -0600, Miguel wrote:
>>  
>>
>>>Ok, the easiest way is create a secuence, but i really need that all the 
>>>columns have unique values, so i will go with the multiple column key, 
>>>only 6 columns should not be a problem to slony ,  should it?  :-)
>>>    
>>>
>>
>>It oughta work.  You might find that performance will improve,
>>however, if you _also_ add an artificial key.
>>
>>A
>>
>>  
>>
> what do you mean by artificial?, the secuence or specify a candidate key 
> with

He means the extra serial column.

The difference it makes for slony is that the commands for replicating 
UPDATE and DELETE operations will read

    ... WHERE "col1" = 'val1' AND "col2" = 'val2' ... "col6" = 'val6'

causing an index lookup with a 6-column scankey instead of a single 
int4/int8 column one. Sure, that scan will be more expensive. But I 
think Andrew forgot that using an artificial serial column means that 
your origin and subscribers must maintain an additional index on all 
insert/update operations (and vacuum must clean it up after deletes).

Andrew, do you have actual experience that it will perform better, or 
was that an assumption?


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 #