Ð
Попов Алексей
Мне и надо посторно читать, просто хотелось бы сразу пачку строк считать
в этом нет необходимости, ридлайн тебе выдаст строки, столько сколько их влезло в чанк, скорость от этого вряд ли изменится
Size: a a a
2020 January 24
ПА
Ð
в этом нет необходимости, ридлайн тебе выдаст строки, столько сколько их влезло в чанк, скорость от этого вряд ли изменится
Спасибо, я понял
Ð
для базы наоборот лучше когда много мелких запросов, меньше блокировок.
ПА
Ð
для базы наоборот лучше когда много мелких запросов, меньше блокировок.
В этом нет необходимости, мне надо как можно быстрее все данные поместить, там несколько гигабайт просто
ПА
База новая
Ð
а субд какая?
ПА
Ее никто не юзает
ПА
Mssql
ПА
Ну пока никто не юзает))
Ð
а, если база не используется, тогда вообще без разницы, запрос закешируй в стейтмент чтобы она его не парсила каждый раз
ПА
Или может процедуру просто
Ð
запрос вызова процедуры тоже надо парсить, лучше стейтмент. Или вообще запиши csv файл а потом скорми его базе, я не знаю будет ли это быстрее, наверное будет
ПА
Передавая туда значения
ПА
Ð
запрос вызова процедуры тоже надо парсить, лучше стейтмент. Или вообще запиши csv файл а потом скорми его базе, я не знаю будет ли это быстрее, наверное будет
Мне коллеги кто с mssql работает про csv тоже говорили
Ð
но я не думаю что разница между csv и prepared statement будет заметной
Ð
оно все равно приведет к запуску одних и тех же механизмов по идее
ПА
Ð
но я не думаю что разница между csv и prepared statement будет заметной
Т.е. через стейтмент по одному запросу быстрее чем много инсертов в транзакции
Ð
весь смысл в избавлении от парсинга запроса на каждую строку
Ð
Попов Алексей
Т.е. через стейтмент по одному запросу быстрее чем много инсертов в транзакции
транзакции нужны для изоляции от других запросов, а тут других нет, они могут не ускорить а наоборот :) я бы не парился, просто делал инсерты через ps, можешь сделать и через csv и протестить на первом миллионе строк например.
ПА
Понял, лучше отогда на стейтмент сделаю, а то csv еще же генерить надо