Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function

From: Lennin Caro <lennin(dot)caro(at)yahoo(dot)com>
To: pgsql-general(at)postgresql(dot)org, Tguru <guru(at)talend(dot)com>
Subject: Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function
Date: 2009-06-29 15:21:43
Message-ID: 627796.747.qm@web59510.mail.ac4.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

--- On Mon, 6/29/09, Tguru <guru(at)talend(dot)com> wrote:

> From: Tguru <guru(at)talend(dot)com>
> Subject: Re: [GENERAL] Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function
> To: pgsql-general(at)postgresql(dot)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/

Browse pgsql-general by date

  From Date Subject
Next Message Pedro Doria Meunier 2009-06-29 15:39:57 Re: Slony-I timezone setting
Previous Message Tom Lane 2009-06-29 15:04:45 Re: Slony-I timezone setting