Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
 Re: Firebird vs MS SQL  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 16403
Симонов Денис,

Я имел в виду ISO SQL 2008, а не Firebird.
20 фев 19, 10:03    [21815155]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9827
WildSery,

вот как раз там и есть тот синтаксис что я привёл. Его кстати почти во всех последних версиях SQL серверов прикрутили в том числе и в Oracle, MS SQL Server
20 фев 19, 10:13    [21815161]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

Откуда:
Сообщений: 10967
Molochnik
Т.е если сделать ускорение только для обычного приоритета


почему для обычного, делай для всех

Molochnik
Приоритет меняется от 1 до 5 в двух используемых таблицах


можно вообще сделать таблицу Максимальный_Приоритет с одной единственнйо строкой и заполнять её на триггерах.

или тупо в клиенте сделать цикл по приоритетам, как только нашлась первая запись, цикл прерывать

и поскольку тебе все равно никогда больше одоной строки не надо, то вместо "ORDER BY tbl1.Priority DESC" написать "WHERE tbl1.Priority = ( SELECT MAX (tbl1.Priority) )"

Но IMHO зря это. Лучше реально считывать пачками хотя бы пару десятков задач, а потом уже на клиенте их разбирать по потокам. Впрочем, если обработка задачи по 10 секунд... (интересно, почему так долго)

SQL апдейт очень простой:
UPDATE tbl1 SET TextMarked=1
WHERE TextId=:TextId


Вот это мне тоже не нравится.
Я бы лучше сделал таблицу-очередь и в неё вставлял Приоритет + ID обработчика + ID задачи (ссылку на таблицу/таблицы с задачами).
Соответственно, при ошибке в обработчике можно задачу возвращать в пул "неназначенных".
При Успешной обработке - просто удалять из таблицы.

У тебя же похоже что во-первых идёт модификация "широкой" таблицы по одному столбцу.
Во вторых получается таблица, где TextMarked=0 выполняется только у очень немногих записей.
Кажется считается, что индексы по таким столбцам неэффективны.
20 фев 19, 20:08    [21815786]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 130
Arioch
или тупо в клиенте сделать цикл по приоритетам, как только нашлась первая запись, цикл прерывать

Да, вариант рабочий, я просто хотел обойтись одним запросом
Arioch
и поскольку тебе все равно никогда больше одоной строки не надо, то вместо "ORDER BY tbl1.Priority DESC" написать "WHERE tbl1.Priority = ( SELECT MAX (tbl1.Priority) )"

Это не прокатит, может быть так, что запись с максимальным приоритетом не удовлетворяет другим условиям, например по времени, а записи с меньшим - удовлетворяют. В итоге, при наличии реальных записей система будет стоять.
Arioch
Но IMHO зря это. Лучше реально считывать пачками хотя бы пару десятков задач, а потом уже на клиенте их разбирать по потокам.

Да уже предлагали этот вариант (Дегтярев Евгений) - один поток, обработчик базы, раскидывает данные по потокам. Я предположил что это чересчур сложно, имея сервер БД, который в общем то должен сам решать эту задачу
Arioch
Впрочем, если обработка задачи по 10 секунд... (интересно, почему так долго)

Пользователь долго думает.
Arioch
Вот это мне тоже не нравится.
Я бы лучше сделал таблицу-очередь и в неё вставлял Приоритет + ID обработчика + ID задачи (ссылку на таблицу/таблицы с задачами).
Соответственно, при ошибке в обработчике можно задачу возвращать в пул "неназначенных".
При Успешной обработке - просто удалять из таблицы.

В общем то примерно так оно сейчас и работает, когда я добавил синтетическое поле приоритета
Arioch
У тебя же похоже что во-первых идёт модификация "широкой" таблицы по одному столбцу.
Во вторых получается таблица, где TextMarked=0 выполняется только у очень немногих записей.

50 тыс записей, 10 потоков, т.е. TextMarked=0 у 49990 записей. Очень немного записей (обычно 0) получается когда не выполняется условие, подобное для всех, например время. Тут сразу получается очень долго. Очевидный вариант решения, который приходит в голову, это сделать еще один запрос, выдающий возможные по условию TaskID (это к примеру на предыдущей странице) и только по ним делать выборку:
SELECT TaskID FROM Table2 WHERE Condition=1

и затем цикл по всем полученнным TaskId:
SELECT Info FROM Table1 LEFT JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table1.TaskId=:TaskId

Как сделать такой же эффективный один запрос я не знаю.
21 фев 19, 09:38    [21816024]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
m7m
Member

Откуда: Украина, Мариуполь
Сообщений: 1347
Molochnik
Очевидный вариант решения, который приходит в голову, это сделать еще один запрос, выдающий возможные по условию TaskID (это к примеру на предыдущей странице) и только по ним делать выборку:
SELECT TaskID FROM Table2 WHERE Condition=1


и затем цикл по всем полученнным TaskId:
SELECT Info FROM Table1 LEFT JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table1.TaskId=:TaskId


Как сделать такой же эффективный один запрос я не знаю.

Встряну в середину разговора
Если уже получил нужные TaskID из Table2 в первом запросе то зачем
JOIN да еще и LEFT во втором
Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем
SELECT .... FROM Table1  JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table2.Condition=1
21 фев 19, 09:59    [21816034]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
m7m
Member

Откуда: Украина, Мариуполь
Сообщений: 1347
Molochnik
Очевидный вариант решения, который приходит в голову, это сделать еще один запрос, выдающий возможные по условию TaskID (это к примеру на предыдущей странице) и только по ним делать выборку:
SELECT TaskID FROM Table2 WHERE Condition=1


и затем цикл по всем полученнным TaskId:
SELECT Info FROM Table1 LEFT JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table1.TaskId=:TaskId


Как сделать такой же эффективный один запрос я не знаю.

Встряну в середину разговора
Если уже получил нужные TaskID из Table2 в первом запросе то зачем
JOIN да еще и LEFT во втором
Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем
SELECT .... FROM Table1  JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table2.Condition=1
21 фев 19, 09:59    [21816035]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1642
Molochnik,

> > Я бы лучше сделал таблицу-очередь и в неё вставлял Приоритет + ID обработчика + ID задачи (ссылку на таблицу/таблицы с задачами).
> В общем то примерно так оно сейчас и работает, когда я добавил синтетическое поле приоритета
примерно да не так
не первый раз говорят - сделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей, постройте индексы покрывающие ваши кейсы и крутите ее как угодно, разделите захват таска и получение данных по нему

зы
и даже без индексов, 50т записей в табличке с десятком целых полей - фильтр + сортировка + получение первой записи менее 50мс
21 фев 19, 10:22    [21816050]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 130
m7m
Встряну в середину разговора
Если уже получил нужные TaskID из Table2 в первом запросе то зачем
JOIN да еще и LEFT во втором
Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем
SELECT .... FROM Table1  JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table2.Condition=1

Пример просто был вырожденный чересчур, реально в Table2 имеются еще полезные поля которые нужно извлечь с помощью JOIN.
Да действительно, заменить LEFT на INNER в голову не приходило, раньше где ни использовал INNER, всегда медленно было, а сейчас протестировал с INNER - мгновенно происходит при невыполнении условия
Дегтярев Евгений
не первый раз говорят - сделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей, постройте индексы покрывающие ваши кейсы и крутите ее как угодно, разделите захват таска и получение данных по нему

зы
и даже без индексов, 50т записей в табличке с десятком целых полей - фильтр + сортировка + получение первой записи менее 50мс

так почти все поля и нужны (процентов 70), если все вносить в одну таблицу, то постоянно придется отслеживать все изменения в исходных, коих различных 6 штук, но вариант конечно рабочий
21 фев 19, 12:46    [21816205]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 130
Molochnik
Да действительно, заменить LEFT на INNER в голову не приходило, раньше где ни использовал INNER, всегда медленно было, а сейчас протестировал с INNER - мгновенно происходит при невыполнении условия

А нет, все от данных зависит, сейчас тестировал на 200 тыс идентичных записях в обоих серверах. Составил табличку

1)Если нет ни одной удовлетворяющей записи,
FB
INNER JOIN - 1.6 сек
LEFT JOIN - 5.5 сек

MS
INNER JOIN - 0.6 сек,
LEFT JOIN - 0.6 сек

2) Если из 200 тыс доступны по условию все, то при получении одной записи
FB
INNER JOIN - 20 сек,
LEFT JOIN - 0.8 секунды

MS
INNER JOIN - 0.01 сек
LEFT JOIN - 0.01 сек

Последние результаты для FB просто удручающие
21 фев 19, 14:56    [21816444]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9827
Molochnik,

я тебе уже советовал отделять условия фильтрации от остальных данных?

делай так

SELECT COUNT(*)
FROM T1 JOIN T2 ....
WHERE <твой фильтр>


если этот запрос будет быстро работать, то и остальное заработает.
21 фев 19, 15:08    [21816473]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

Откуда:
Сообщений: 10967
Molochnik
Это не прокатит, может быть так, что запись с максимальным приоритетом не удовлетворяет другим условиям, например по времени, а записи с меньшим - удовлетворяют.


Хммм... Ну тогда вот именно в этом случае, относительно редком, и "сыграешь на понижение", сделаешь второй запрос

Arioch
"WHERE tbl1.Priority = ( SELECT MAX (tbl1.Priority) ) - :StepDown "


StepDown = 0, 1, 2, 3....

Molochnik
имея сервер БД, который в общем то должен сам решать эту задачу


количество действий на вытаскивание одного задания, в процентах на непосредственно получения задания, и на обрамление

для многопоточности есть вообще такие заморочки, как "безблокировочные структуры данных", которые весьма сложные и баго-опасные, но ими занимаются.

потому что чем дольше у тебя процессор занимается действием "получить следующий элемент" - тем боьлше вероятность, что два таких действия с разных процессоров пересекутся. Тем, соотв., больше вероятность - что процессор будет работать "на мусорное ведро".

Даже вот тупо так:

процессор 1 начал получать задание
процессор 2 начал получать задание
процессор 1 получил задание №1
процессор 2 получил задание №1
процессор 1 начал обрабатывать задание №1
процессор 2 начал обрабатывать задание №1
процессор 1 кончил обрабатывать задание №1
процессор 2 кончил обрабатывать задание №1
процессор 1 положил в БД задание №1
процессор 2 попытался положить в БД задание №1 - и обломался (а то, не дай бог, и положил, дубль)
процессор 1 начал получать задание
процессор 2 начал получать задание
процессор 1 получил задание №2
процессор 2 получил задание №2
....

если задания примерно равнозначные по сложности - то такая цепочка может дооолго идти.
а если процессоров >2 - то ещё дольше.
21 фев 19, 15:15    [21816489]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

Откуда:
Сообщений: 10967
Molochnik
В общем то примерно так оно сейчас и работает, когда я добавил синтетическое поле приоритета


ну сиииииильно примерно, учитывая что вместо одной таблицы у тебя джойн полудесятка

и учитывая, что отработанные записи вместо простого удаления из таблицы помечаются отдельным столбцом TextMarked - который вообще нафиг не нужен. Просто удаляй отработанную запись из таблицы.

Molochnik
50 тыс записей, 10 потоков, т.е. TextMarked=0 у 49990 записей.

это сегодня.
завтра у тебя 50К с 0 и 50К с 1
послезавтра - 50К с 0 и 100К с 1
через месяц - 50К с 0 и 3М с 1
и т.д.
21 фев 19, 15:20    [21816496]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

Откуда:
Сообщений: 10967
Дегтярев Евгений
не первый раз говорят - сделайте отдельную узкую таблицу для очереди


туда ещё и генератор можно будет прицепить, ради dirty read, ради того, чтобы "захват таска" выполнялся вообще ВНЕ ТРАНЗАКЦИЙ и таким образом два разных клиента просто В ПРИНЦИПЕ не могли схватить один и тот же таск

да, надо будет отрабатывать ошибочные ситуации типа "клиент схватил таск и умер, а уборщица украла сетевой кабель" - вбрасывать задание обратно с новым ID > generator-value

но захват пачки заданий становится максимально быстрым и вообще без возможных пересечений с конкурентами
21 фев 19, 15:24    [21816502]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

Откуда:
Сообщений: 10967
Molochnik
Последние результаты для FB просто удручающие


а если перед запуском запроса выключать службы FB и MS SQL, а потoм снoва их включать и запрос прогонять на "холодной" базе (т.е. убрать влияние кэшей) ?
21 фев 19, 15:27    [21816507]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 783
Molochnik,

20 сек - это, конечно, сильно. Может анализ производительности в Эксперте посмотрим? План?
21 фев 19, 15:42    [21816527]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 130
Arioch
Molochnik
Последние результаты для FB просто удручающие

а если перед запуском запроса выключать службы FB и MS SQL, а потoм снoва их включать и запрос прогонять на "холодной" базе (т.е. убрать влияние кэшей) ?

Да сделал так, еще дополнительно провел бэкап рестор базы, результаты получше стали
1)Если нет ни одной удовлетворяющей записи,
FB
INNER JOIN - 1.2 сек
LEFT JOIN - 4.1 сек

2) Если из 200 тыс доступны по условию все, то при получении одной записи
FB
INNER JOIN - 17 сек,
LEFT JOIN - 0.015 сек

То есть в идеальном случае, когда любая запись подходит FB работает почти как MS, что не может не радовать. Но INNER JOIN просто смерть какая-то.
21 фев 19, 16:10    [21816570]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
m7m
Member

Откуда: Украина, Мариуполь
Сообщений: 1347
Molochnik
Но INNER JOIN просто смерть какая-то.

Вот тут ты не прав
нельзя просто так заменить LEFT JOIN на INNER JOIN
ибо это совершенно разные запросы и
совершенно разные результаты выполнения

зы.
не видя ни структур таблиц, ни планов, ни запросов
мы тебе тут много чего насоветуем

ззы. то что я написал относилось конкретно к тем двум запросам что были в сообщении
и никак не означало что надо заменить LEFT JOIN на INNER JOIN в твоем исходном запросе
21 фев 19, 16:45    [21816603]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 597
Molochnik
Arioch
пропущено...

а если перед запуском запроса выключать службы FB и MS SQL, а потoм снoва их включать и запрос прогонять на "холодной" базе (т.е. убрать влияние кэшей) ?

Да сделал так, еще дополнительно провел бэкап рестор базы, результаты получше стали
1)Если нет ни одной удовлетворяющей записи,
FB
INNER JOIN - 1.2 сек
LEFT JOIN - 4.1 сек

2) Если из 200 тыс доступны по условию все, то при получении одной записи
FB
INNER JOIN - 17 сек,
LEFT JOIN - 0.015 сек

То есть в идеальном случае, когда любая запись подходит FB работает почти как MS, что не может не радовать. Но INNER JOIN просто смерть какая-то.


Да план меняется просто при заменах inner-left. Порядок перебора таблиц и, соответственно, используемые индексы. При left порядок задан жёстко, при inner его определяет оптимизатор. Опираясь на статистику индексов. Но он не знает сколько у тебя в какой таблице дубликатов по индексам и, бывает, оптимизирует не в ту сторону. А у тебя их, дубликатов, сорок бочек арестантов. Но ты-то об этом знаешь, так и направляй оптимизатора через +0 для того, чтобы он не использовал заведомо вредные для этого конкретного запроса индексы. В смысле чтобы добиться среднестатистической оптимальности, по наиболее распространённому случаю. Кстати, сортировки тоже тормозят тем сильнее, чем больше дубликатов по этим полям. Если их нет, то почти что с сортировкой, что без.
21 фев 19, 19:03    [21816776]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 130
Симонов Денис
Molochnik,

я тебе уже советовал отделять условия фильтрации от остальных данных?

делай так

SELECT COUNT(*)
FROM T1 JOIN T2 ....
WHERE <твой фильтр>


если этот запрос будет быстро работать, то и остальное заработает.

Потестировал ваш вариант, оставил одно поле
COUNT(*) 
и убрал
ORDER BY
иначе выдавал ошибку. Результаты следующие:
1)Если нет ни одной удовлетворяющей записи (Count =0)
FB
INNER JOIN - 1.3 сек
LEFT JOIN - 3.8 сек

MS
INNER JOIN - 0.005 сек,
LEFT JOIN - 0.005 сек

2) Если из 200 тыс доступны по условию все ( Count =200000)
FB
INNER JOIN - 4.2 сек,
LEFT JOIN - 4.2 сек

MS
INNER JOIN - 0.7 сек
LEFT JOIN - 0.7 сек
m7m
Вот тут ты не прав
нельзя просто так заменить LEFT JOIN на INNER JOIN
ибо это совершенно разные запросы и
совершенно разные результаты выполнения

В общем случае согласен, но в моем варианте и варианте тестового примера, когда возвращается одна строка результат по логике должен быть примерно одинаковым, что результаты MS в общем то доказывают.
21 фев 19, 19:09    [21816781]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 130
m7m
не видя ни структур таблиц, ни планов, ни запросов
мы тебе тут много чего насоветуем

ззы. то что я написал относилось конкретно к тем двум запросам что были в сообщении
и никак не означало что надо заменить LEFT JOIN на INNER JOIN в твоем исходном запросе

Реально там нет ничего интересного, ну вообще ничего, 6 таблиц джойнятся с разными несложными разумными условиями, никаких нестед таблиц или сложных конструкций, две таблицы большие да, по 200 тыс записей, джойнятся один к одному по полю, которое в одной таблице уникально, остальные таблицы по 1-3 записи. Основная проблема судя по всему - очень много одинаковых значений по полям, которые используется при сортировке и фильтре.
Старый плюшевый мишка
Да план меняется просто при заменах inner-left. Порядок перебора таблиц и, соответственно, используемые индексы. При left порядок задан жёстко, при inner его определяет оптимизатор. Опираясь на статистику индексов. Но он не знает сколько у тебя в какой таблице дубликатов по индексам и, бывает, оптимизирует не в ту сторону. А у тебя их, дубликатов, сорок бочек арестантов. Но ты-то об этом знаешь, так и направляй оптимизатора через +0 для того, чтобы он не использовал заведомо вредные для этого конкретного запроса индексы. В смысле чтобы добиться среднестатистической оптимальности, по наиболее распространённому случаю. Кстати, сортировки тоже тормозят тем сильнее, чем больше дубликатов по этим полям. Если их нет, то почти что с сортировкой, что без.

Это пока для меня слишком сложно, я сейчас почитаю как работает FB (ссылку дали). Но что интересно, если у меня был только MS, я бы и думать не знал что имеется какой-то "оптимизатор", который иногда работает плохо и его надо както "поправлять" :)
21 фев 19, 19:24    [21816792]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Фэйтл Эра
Member

Откуда:
Сообщений: 627
Molochnik
если у меня был только MS, я бы и думать не знал что имеется какой-то "оптимизатор", который иногда работает плохо и его надо както "поправлять"

Ты просто пока не сталкивался. Например, выполни поиск слова "хинт" в форуме https://www.sql.ru/forum/microsoft-sql-server.
21 фев 19, 19:35    [21816802]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9827
Molochnik,

упрости запрос по максимуму на которых проявляются тормоза. Приведи его здесь, статистику выполнения и explain план запроса.
Кстати в MS SQL ном варианте тоже хотелось бы на план взглянуть
21 фев 19, 19:47    [21816815]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 597
Molochnik
Это пока для меня слишком сложно, я сейчас почитаю как работает FB (ссылку дали). Но что интересно, если у меня был только MS, я бы и думать не знал что имеется какой-то "оптимизатор", который иногда работает плохо и его надо както "поправлять" :)


IBExpert внизу, вместе со временем выполнения, показывает пресловутый план. Перечень использованных индексов. Причём они перечисляются в порядке перебора таблиц, на которых они созданы. То есть, индексы таблицы, от которой начинается перебор, идут первыми (если она вообще не идёт натуралом), первого уровня подчинённости - вторыми и так далее. Скажем, условие "on t1.id=t2.id" в иннер может быть выполнено как перебором t1 с подтягиванием записей из t2 по индексу на t2, так и наоборот. Посмотри на план и прикинь как ТЫ бы это делал сам, ручками, чтобы не за... за... устать, в общем. И если оптимизатор сделал наоборот, то имеем то, что имеем, и надо вправлять ему мозги подзатыльником. Типа "on t1.id+0=t2.id". Тогда t1 точно будет ведущей, а t2 подтягиваться по индексу.
21 фев 19, 20:13    [21816831]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 130
Симонов Денис
Старый плюшевый мишка
Да все сделаю, посмотрю и проверю
21 фев 19, 20:28    [21816840]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

Откуда:
Сообщений: 10967
Старый плюшевый мишка
IBExpert внизу, вместе со временем выполнения, показывает пресловутый план


там ещё статистика чтений показываетсЯ, сколько с диска и сколько с кэша в памяти

особенно еслди сравнить один и тот же запрос по холодному и по горячему

вполне возможно, что часть преимущества MS SQL просто в бОльшем кэше
22 фев 19, 14:18    [21817307]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Firebird, InterBase Ответить