Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
От | Tom Lane |
---|---|
Тема | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) |
Дата | |
Msg-id | 2587470.1675660337@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) (Damir Belyalov <dam.bel07@gmail.com>) |
Ответы |
Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
|
Список | pgsql-hackers |
Damir Belyalov <dam.bel07@gmail.com> writes: >> I don't think this is the right approach. Creating a subtransaction for >> each row will cause substantial performance issues. > Subtransactions aren't created for each row. The block of rows in one > subtransaction is 1000 (SAFE_BUFFER_SIZE) and can be changed. I think that at this point, any patch that involves adding subtransactions to COPY is dead on arrival; whether it's batched or not is irrelevant. (It's not like batching has no downsides.) > InputFunctionCallSafe() is good for detecting errors from input-functions > but there are such errors from NextCopyFrom () that can not be detected > with InputFunctionCallSafe(), e.g. "wrong number of columns in row''. If you want to deal with those, then there's more work to be done to make those bits non-error-throwing. But there's a very finite amount of code involved and no obvious reason why it couldn't be done. The major problem here has always been the indefinite amount of code implicated by calling datatype input functions, and we have now created a plausible answer to that problem. regards, tom lane
В списке pgsql-hackers по дате отправления: