Re: Seq scans roadmap

From: "CK Tan" <cktan(at)greenplum(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Luke Lonergan" <llonergan(at)greenplum(dot)com>, "Simon Riggs" <simon(at)enterprisedb(dot)com>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>, "Jeff Davis" <pgsql(at)j-davis(dot)com>
Subject: Re: Seq scans roadmap
Date: 2007-05-14 02:36:57
Message-ID: AC541650-FB8C-4011-8D3E-5931556DA5C8@greenplum.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sorry, I should have been clearer. I meant because we need to check
for trigger firing pre/post insertion, and the trigger definitions
expect tuples to be inserted one by one, therefore we cannot insert N-
tuples at a time into the heap. Checking for triggers itself is not
taking up much CPU at all. If we could predetermine that there is not
any triggers for a relation, inserts into that relation could then
follow a different path that inserts N-tuples at a time.

Regards,
-cktan

On May 13, 2007, at 4:54 PM, Tom Lane wrote:

> "CK Tan" <cktan(at)greenplum(dot)com> writes:
>> COPY/INSERT are also bottlenecked on record at a time insertion into
>> heap, and in checking for pre-insert trigger, post-insert trigger and
>> constraints.
>
>> To speed things up, we really need to special case insertions without
>> triggers and constraints, [probably allow for unique constraints],
>
> Do you have any profiling data to back up these assertions? I haven't
> noticed that firing zero tuples takes any visible percentage of COPY
> time.
>
> regards, tom lane
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2007-05-14 03:58:14 Concurrently updating an updatable view
Previous Message Tom Lane 2007-05-14 01:55:01 Re: Concurrent psql patch