Re: Append table

From: "Hanu Kurubar" <hanu(dot)kurubar(at)gmail(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Michal Szymanski" <szymanskim(at)gdfi(dot)pl>, "Michal Szymanski" <szymanskim(at)datera(dot)pl>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Append table
Date: 2007-06-02 15:52:08
Message-ID: 912b58490706020852r61d308b3m595bf410d89a113@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Any luck on appending two table in PostgreSQL.
Below are two table with same schema that have different values. In this
case EmpID is unique value.

tabelA
------------
EmpId (Int) EmpName (String)
1 Hanu
2 Alvaro

tabelB
------------
EmpId (Int) EmpName (String)
3 Michal
4 Tom

I would be looking below output after appending tableA with tableB. Is this
possible in PostgreSQL?

tabelA
------------
EmpId (Int) EmpName (String)
1 Hanu
2 Alvaro
3 Michal
4 Tom

Thanks,
Hanu

On 5/30/07, Hanu Kurubar <hanu(dot)kurubar(at)gmail(dot)com> wrote:
>
> Can you help me appending two table values into single table without
> performing INSERT?
> Note that these tables are of same schema.
>
> Is there any sql command is supported?
>
> Thanks,
> Hanu
>
>
> On 5/29/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> >
> > Michal Szymanski wrote:
> > > There is another strange thing. We have two versions of our test
> > > >>environment one with production DB copy and second genereated with
> > > >>minimal data set and it is odd that update presented above on copy
> > of
> > > >>production is executing 170ms but on small DB it executing 6s !!!!
> > > >
> > > >How are you vacuuming the tables?
> > > >
> > > Using pgAdmin (DB is installed on my laptop) and I use this tool for
> > > vaccuminh, I do not think that vaccuming can help because I've tested
> > on
> > > both database just after importing.
> >
> > I think you are misunderstanding the importance of vacuuming the table.
> > Try this: on a different terminal from the one running the test, run a
> > VACUUM on the updated table with vacuum_cost_delay set to 20, on an
> > infinite loop. Keep this running while you do your update test. Vary
> > the vacuum_cost_delay and measure the average/min/max UPDATE times.
> > Also try putting a short sleep on the infinite VACUUM loop and see how
> > its length affects the UPDATE times.
> >
> > One thing not clear to me is if your table is in a clean state. Before
> > running this test, do a TRUNCATE and import the data again. This will
> > get rid of any dead space that may be hurting your measurements.
> >
> > --
> > Alvaro Herrera
> > http://www.advogato.org/person/alvherre
> > "The Postgresql hackers have what I call a "NASA space shot" mentality.
> > Quite refreshing in a world of "weekend drag racer" developers."
> > (Scott Marlowe)
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
>
>
>
> --
> With best regards,
> Hanumanthappa Kurubar
> Mobile: 98 801 800 65

--
With best regards,
Hanumanthappa Kurubar
Mobile: 98 801 800 65

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Arjen van der Meijden 2007-06-02 16:04:19 Re: Append table
Previous Message Kenneth Marshall 2007-06-02 15:45:22 Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x