Nikolay Ponomarenko ...
Hello, Vlad!
You wrote on Fri, 17 Apr 2009 09:13:56 +0300:
VK Одни и теже страницы пишутся многократно. У тебя там нет
VK повторных апдейтов одной и той же записи в одной тр-ции ?
Нет, апдейты уникальные, т.е. по одному на запись.
KV Триггеры ?
На время
On Fri, 17 Apr 2009 22:44:44 +0400, Vlad Khorsun hv...@optima.com.ua wrote:
N.B. На самом свежем FB Влад говорил протокол настолько хорошо оптимизирован,
что разница временами почти не заметна.
Не мог он такого говорить. Или ты о каком Владе ?
:) беру слова назад.
Вероятно, это мои
Nikolay Ponomarenko ...
Hello, Vlad!
You wrote on Fri, 17 Apr 2009 21:44:44 +0300:
А как EB мог бы помочь? Несколько раз встречал упоминание, но так и не
понял в чем теоретически можно выйграть, если все через отпрепаренный
запрос делается?
По сети кидается одним пакетом. Нет обмена
Nikolay Ponomarenko ...
Hello, Vlad!
You wrote on Thu, 16 Apr 2009 13:35:29 +0300:
AC Сервер и клиент на одной железяке?
Более того, embeded.
VK Потому и разница мала. Но всё равно она должна быть. Ибо постоянный
VK prepare.
Ну препар, он ведь в основном процессор нагружает. И если
On Fri, 17 Apr 2009 19:31:02 +0400, Nikolay Ponomarenko pnv...@gmail.com
wrote:
А как EB мог бы помочь? Несколько раз встречал упоминание, но так и не понял
в чем теоретически можно выйграть, если все через отпрепаренный запрос
делается?
По сети кидается одним пакетом. Нет обмена туда-сюда.
WildSery ...
On Fri, 17 Apr 2009 19:31:02 +0400, Nikolay Ponomarenko :
А как EB мог бы помочь? Несколько раз встречал упоминание, но так и не понял
в чем теоретически можно выйграть, если все через отпрепаренный запрос
делается?
По сети кидается одним пакетом. Нет обмена туда-сюда.
Nikolay Ponomarenko wrote:
Кстати, я правильно помню, что версия _всей_ записи создается даже при
холостом апдейте или апдейте теми же данными?
Версия - это дифф. Ни о какой _всей_ речи идти не может.
--
Дмитрий Еманов
Nikolay Ponomarenko wrote:
да, вдруг у кого будут мысли, как можно ускорить построчный апдейт
200тыс записей - сейчас это порядка 3-4 минут на 50мб/с винте.
Forced Writes отключен?
Nikolay Ponomarenko ...
Hello, Alex!
You wrote to Nikolay Ponomarenko on Thu, 16 Apr 2009 13:34:17 +0400:
NP Считал что второй вариант однозначно быстрее, но практический тест
NP показывает сравнимые результаты :-/
AC Сервер и клиент на одной железяке?
Более того, embeded.
Потому и
Dmitry Kotelnikov wrote:
Приветствую Вас,
Скажите что на практике быстрее:
1. Проверка через SELECT на наличие записи и потом выполнить INSERT
если нет записи или UPDATE если есть.
или
2. Делать DELETE и INSERT
По-моему, (2) вообще не катит, а конкретный вариант из указанной ссылки
надо
Приветствую Вас,
Скажите что на практике быстрее:
1. Проверка через SELECT на наличие записи и потом выполнить INSERT
если нет записи или UPDATE если есть.
или
2. Делать DELETE и INSERT
Спасибо.
PS: REPLACE или INSERT OR UPDATE не предлагать, т.к. версия 1.5.
--
С Уважением, Дмитрий
Dmitry Kotelnikov wrote:
Скажите что на практике быстрее:
1. Проверка через SELECT на наличие записи и потом выполнить INSERT
если нет записи или UPDATE если есть.
или
2. Делать DELETE и INSERT
http://www.ibase.ru/devinfo/testiu.htm
--
Regards. Ded.
Самый тормозной понятно
select count(*) from table
А вот два вроде бы довольно быстрых кандидата:
1) select first 1 1 from table
2) select iif(exists(select 1 from table, 1, 0) from rdb$database
Какой будет наиболее быстрый?
Tonal пишет:
Самый тормозной понятно
select count(*) from table
А вот два вроде бы довольно быстрых кандидата:
1) select first 1 1 from table
2) select iif(exists(select 1 from table, 1, 0) from rdb$database
Какой будет наиболее быстрый?
А попробовать?
--
С уважением,
Андрей Еремин.
if exists(select * from table)
then
букофф меньше
--
Булычев Алексей
http://www.stella-npf.ru
Andrei Yeryomin пишет:
1) select first 1 1 from table
2) select iif(exists(select 1 from table, 1, 0) from rdb$database
Какой будет наиболее быстрый?
А попробовать?
Попробовал.
Разницы не ощутил, вот и спрашиваю тут. ;-)
Возможно разница будет проявляться при каких-то специфичных условиях
16 matches
Mail list logo