On Wed, Mar 30, 2011 at 01:16, Samuel Gendler <sgend...@ideasculptor.com> wrote: > I've got some functionality that necessarily must scan a relatively large > table
> Is there any performance benefit to revamping the workload such that it issues > a single: > insert into (...) select ... UNION select ... UNION select > as opposed to 3 separate "insert into () select ..." statements. Apparently not, as explained by Claudio Freire. This seems like missed opportunity for the planner, however. If it scanned all three UNION subqueries in parallel, the synchronized seqscans feature would kick in and the physical table would only be read once, instead of 3 times. (I'm assuming that seqscan disk access is your bottleneck) You can trick Postgres (8.3.x and newer) into doing it in parallel anyway: open 3 separate database connections and issue each of these 'INSERT INTO ... SELECT' parts separately. This way all the queries should execute in about 1/3 the time, compared to running them in one session or with UNION ALL. Regards, Marti -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
