On 3/29/11 3:16 PM, Samuel Gendler wrote:
I've got some functionality that necessarily must scan a relatively large
table. Even worse, the total workload is actually 3 similar, but different
queries, each of which requires a table scan. They all have a resultset that
has the same structure,
On Tue, Mar 29, 2011 at 5:05 PM, Marti Raudsepp wrote:
> On Wed, Mar 30, 2011 at 01:16, Samuel Gendler
> wrote:
>
> 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 separatel
On Wed, Mar 30, 2011 at 01:16, Samuel Gendler 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
On Tue, Mar 29, 2011 at 7:16 PM, Samuel Gendler
wrote:
> 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.
I wouldn't expect any
I've got some functionality that necessarily must scan a relatively large
table. Even worse, the total workload is actually 3 similar, but different
queries, each of which requires a table scan. They all have a resultset
that has the same structure, and all get inserted into a temp table. Is
the
