Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function - Mailing list pgsql-general

From Lennin Caro
Subject Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function
Date
Msg-id 627796.747.qm@web59510.mail.ac4.yahoo.com
Whole thread Raw
In response to Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function  (APseudoUtopia <apseudoutopia@gmail.com>)
List pgsql-general


--- On Mon, 6/29/09, Tguru <guru@talend.com> wrote:

> From: Tguru <guru@talend.com>
> Subject: Re: [GENERAL] Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function
> To: pgsql-general@postgresql.org
> Date: Monday, June 29, 2009, 1:33 PM
>
> To migrate the site, you can use an open source ETL tool.
>
> Talend Open Studio is an open source ETL tool for data
> integration and
> migration experts. It's easy to learn for a non-technical
> user. What
> distinguishes Talend, when it comes to business users, is
> the tMap
> component. It allows the user to get a graphical and
> functional view of
> integration processes.
> For more information: http://www.talend.com/
>

> Justin-95 wrote:

> >
> >
> > APseudoUtopia wrote:
> >
> >   thread, then logs out (intending to
> read all the other forum threads
> > at some point in the future when they log in again).
> If I used a VIEW,
> > it would automatically consider all those unread forum
> posts to be
> > read when the user logs out.
> >
> >   
> > That wouldn't work. What if a user logs in, reads only
> one forum
> >
> >
> > You are keeping a list of all the forums a user has
> read,  i would not
> > worry about making sure the table tracking user
> activity has duplicate
> > key values. The select can be limited to return just
> on row with the
> > highest time stamp then compare this result to figure
> out what forms
> > the user has not read yet.  This eliminates one of
> problems but creates
> > a problem where table tracking user activity is going
> bloat but in low
> > traffic times delete the duplicate values.
> >
> > A similar topic was discussed  on the performance 
> mailing list, where
> > updates are hung for several seconds for a similar
> tracking table...
> > http://archives.postgresql.org/pgsql-performance/2009-06/msg00300.php
>
> >
> >  
> >
> >
> >
> >


another option is Pentaho, is good and easy too http://kettle.pentaho.org/




pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Slony-I timezone setting
Next
From: Pedro Doria Meunier
Date:
Subject: Re: Slony-I timezone setting