[MDEV-13047] Feature Request: Need BINDSIZE option in LOAD DATA INFILE Created: 2017-06-09  Updated: 2018-08-31  Resolved: 2018-06-21

Status: Closed
Project: MariaDB Server
Component/s: N/A
Fix Version/s: N/A

Type: Task Priority: Major
Reporter: Nilnandan Joshi Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: Compatibility


 Description   

Need BINDSIZE option in LOAD DATA INFILE
https://docs.oracle.com/cd/B19306_01/server.102/b14215/ldr_control_file.htm#i1004788



 Comments   
Comment by Oleksandr Byelkin [ 2017-06-22 ]

Do I understand correctly that the parameter control of size of array of parameters which send via array binding interface of prepared statements. i.e. Oracle load utility uses prepared statements and sands data in chunks (arrays) controlled by this parameter?

If yes then which semantic it should have in MariaDB where LOAD DATA INFILE is an server command and the file read by server (locally or via net with help of client)?

Comment by Alvin Richards (Inactive) [ 2017-06-26 ]

From the Oracle Doc

Size Requirements for Bind Arrays
The bind array must be large enough to contain a single row. If the maximum row length exceeds the size of the bind array, as specified by the BINDSIZE parameter, SQL*Loader generates an error. Otherwise, the bind array contains as many rows as can fit within it, up to the limit set by the value of the ROWS parameter.

The BINDSIZE and ROWS parameters are described in Command-Line Parameters.

Although the entire bind array need not be in contiguous memory, the buffer for each field in the bind array must occupy contiguous memory. If the operating system cannot supply enough contiguous memory to store a field, SQL*Loader generates an error.

Comment by Sergei Golubchik [ 2018-06-20 ]

technically, we can do it. But currently the client-side buffer size for LOAD DATA LOCAL INFILE is

MY_ALIGN(mysql->net.max_packet-16,IO_SIZE)

that is, basically, max_packet_size. It cannot be larger than that anyway. We can allow the user to make is smaller, but why?

Generated at Thu Feb 08 08:02:29 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.