This line from the EXPLAIN output suggests that the rule is causing a
seq scan
to be used instead on an index scan:
... WHERE ... a.archiveset = new.archiveset AND a.fileid <>
new.fileid.
When I replace the "new." with actual integers:
... WHERE ... a.archiveset = 10003 AND a.filei
On 09/13/2012 09:59 AM, Tom Lane wrote:
Alex Lai writes:
"EXPLAIN insert into alex1 (fileid, archiveset) select 35352974, 10003;"
[vs]
"EXPLAIN insert into alex1 (fileid, archiveset) select '35352974', '10003';"
You might be happier using INSERT ... VALUES instead of INSERT
... SELECT
Alex Lai writes:
>"EXPLAIN insert into alex1 (fileid, archiveset) select 35352974, 10003;"
> [vs]
>"EXPLAIN insert into alex1 (fileid, archiveset) select '35352974',
> '10003';"
You might be happier using INSERT ... VALUES instead of INSERT
... SELECT for this. In the former, the parser
alex1 is a table with 47 million rows and a rule that deletes from another
table whenever an insert is made into alex1. Insertions into alex1 are
causing
a seq scan that takes a very long time:
"EXPLAIN insert into alex1 (fileid, archiveset) select 35352974, 10003;"
(EXPLAIN output is at
