Re: Seq scans roadmap - Mailing list pgsql-hackers

From CK Tan
Subject Re: Seq scans roadmap
Date
Msg-id AC541650-FB8C-4011-8D3E-5931556DA5C8@greenplum.com
Whole thread Raw
In response to Re: Seq scans roadmap  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@greenplum.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
>




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Seq scans roadmap
Next
From: Hiroshi Inoue
Date:
Subject: Concurrently updating an updatable view