но понадеялся на то, что где-то за горами, в отличие то меня, есть такие люди,
которые старые баги правят, а новые не вносят :))
Есть такие. Кто тесты правильно применяет, тот снижает это колическтво к
минимуму.
УКРАИНА! ОТДАЙ НАМ НАШУ СОЛЬ!!!
Только если заплатите как за сало!!
Alexander A. Venikov пишет:
Таких людей не бывает ;) Только в легендах про древних программистов. :)
Вообще, по определению, Отладка - поиск и устранение ошибок и
изготовление новых. :)
ОШИБКА - ОТ БОГА. ПОЭТОМУ НЕ СТАРАЙТЕСЬ ИСПРАВИТЬ ОШИБКУ. НАПРОТИВ,
ПОПРОБУЙТЕ ПОНЯТЬ ЕЕ, ПРОНИКНУТЬСЯ
ÐÒÉ×ÅÔ ×ÓÅÍ,
ÅÓÔØ ÂÏÌØÛÏÅ ÐÒÉÌÏÖÅÎÉÅ. ÓÒÅÄÉ ÐÒÏÞÉÈ, ÅÓÔØ ÎÅÓËÏÌØËÏ ÄÅÓÑÔËÏ× ÚÁÐÒÏÓÏ× ÎÁ
ÞÔÅÎÉÅ,
ËÏÔÏÒÙÅ ×ÙÚÙ×ÁÀÔÓÑ ÄÏÓÔÁÔÏÞÎÏ ÞÁÓÔÏ (ÐÏ ÎÅÓËÏÌØËÕ ÄÅÓÑÔËÏ×-ÓÏÔÅÎ ÒÁÚ
ÚÁ ÓÅÁÎÓ). Ó ÔÏÞËÉ ÚÒÅÎÉÑ ×ÎÕÔÒÅÎÎÅÇÏ ÕÓÔÒÏÊÓÔ×Á æÁÊÒÅÂÅÒÄÁ, ÞÔÏ ÌÕÞÛÅ:
1) ÎÁ ËÁÖÄÙÊ ÔÁËÏÊ ÚÁÐÒÏÓ ÏÔËÒÙ×ÁÔØ ÔÒÁÎÚÁËÃÉÀ, ×ÙÐÏÌÎÑÔØ
Hi A K
М.б. я не гуру но ответить из опыта постараюсь :-)
1) на каждый такой запрос открывать транзакцию, выполнять запрос, закрывать
транзакцию
или
2) иметь одну общую транзакцию только для чтения, которая будет всегда
открыта.
подготовить на ней заранее все запросы и по мере
Vlad Horsun [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Oleg LOA ...
Ну, хоть что-то тебе нравится :)
Ты на результаты FB2 посмотри, а архив таки донёс до конфы - всё очень даже.
A K [EMAIL PROTECTED] wrote:
1) на каждый такой запрос открывать транзакцию, выполнять запрос,
закрывать
транзакцию
или
2) иметь одну общую транзакцию только для чтения, которая будет всегда
открыта.
Если транзакция READ COMMITTED, то (2) выгоднее с точки зрения сборки
мусора. Если же
Vlad Horsun [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Oleg LOA ...
В аттаче результаты из Glow Code для 10К и 100К страниц - там всё ясно
Я тебе без PIO_read укажу место где не так :-), у тебя памятьи на машине мало
:-):-):-):-)
Oleg LOA [EMAIL PROTECTED] wrote:
Именно :-)
Если бы не кривой план на 16-м запросе, все было бы очень даже красиво.
--
Дмитрий Еманов
×ÒÏÄÅ ÂÙ ÍÅÓÑÃÁ ÐÏÌÔÏÒÁ ÎÁÚÁÄ äÍÉÔÒÉÊ åÍÁÎÏ× ÔÕÔ ÕÓÔÒÁÉ×ÁÌ ÏÐÒÏÓ ÎÁ ÌÕÞÛÉÊ
×ÁÒÉÁÎÔ ÓÉÎÔÁËÓÉÓÁ ÈÉÎÔÏ× ÄÌÑ ÐÏÄÓËÁÚËÉ ÏÐÔÉÍÉÚÁÔÏÒÕ ËÁË ÓÔÒÏÉÔØ ÐÌÁÎ ÐÏ
ÚÁÐÒÏÓÕ. îÏ ÓÅÊÞÁÓ ÐÒÏÓÍÏÔÒÅÌ ÄÏËÕ ÐÏ âÅÔÁ 2 É ÎÉÞÅÇÏ ÔÁËÏÇÏ ÎÅ ÎÁÛÅÌ. ÷ ÞÅÍ
ÄÅÌÏ?
áÎÄÒÅÊ
А вы какой PG сравнивали? 8.1 или 8.0?
И ещё там я не понял результатов на вкладке FB/PG - где чьи?
И по IB7 что-то невесёлое...
A K [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
2) иметь одну общую транзакцию только для чтения, которая будет всегда
открыта.
подготовить на ней заранее все запросы и по мере обращения к ним подставлять
нужные параметры и выполнять эти запросы.
Вот так будет быстрее всего
A K [EMAIL PROTECTED] wrote:
вроде бы месяца полтора назад Дмитрий Еманов тут устраивал опрос на лучший
вариант синтаксиса хинтов для подсказки оптимизатору как строить план по
запросу. Но сейчас просмотрел доку по Бета 2 и ничего такого не нашел. В
чем дело?
А он что-то говорил про 2.0?
Hello, Dmitry!
You wrote on Wed, 15 Feb 2006 12:26:17 +0300:
?? собственно. мой вопрос такой: не плохо ли это, если несколько десятков
?? запросов будут подготовлены (Prepare) и висеть на протяжении времени
?? работы приложения?
DY Это абсолютно нормально. Кроме того, препарирование запроса к
2) Слухи о тормознутости PG сильно приувеличины :-)
Явно слухи, по крайней мере экстракт метаданных на нем проходит в несколько
раз быстрее чем на других серверах, а про остальное я не в курсе. :-)
Dmitry Yemanov [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Oleg LOA loa-JGs/[EMAIL PROTECTED] wrote:
Именно :-)
Если бы не кривой план на 16-м запросе, все было бы очень даже красиво.
Фиксаем оптимизатор, разбираемся с увеличинным кэшем и тоды да :-)
P.S. Я ещё не проверял
Oleg LOA [EMAIL PROTECTED] wrote:
Фиксаем оптимизатор, разбираемся с увеличинным кэшем и тоды да :-)
Оптимизатор уже в работе. У меня 14 и 16 запросы в блокнотике давно
записаны, но все руки не доходили. Я на TPC-R каждое изменение оптимизатора
тестирую :-)
--
Дмитрий Еманов
Nikolay Ponomarenko [EMAIL PROTECTED] wrote in message news:[EMAIL
PROTECTED]
ручном вызове Unprepare, при разрушении компонента выполнившего
Prepare, при смене текста запроса.
Первый два случая понятны, но вот остальные - зачем?
остальные - это:
3) разрушении компонента выполнившего
Dmitry Yemanov [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Oleg LOA loa-JGs/[EMAIL PROTECTED] wrote:
Фиксаем оптимизатор, разбираемся с увеличинным кэшем и тоды да :-)
Оптимизатор уже в работе. У меня 14 и 16 запросы в блокнотике давно
С кэшем как я понял предложено мне
Что-то я запарился.
Пришла в орган, расположенный на плечах, такая мысль - разрешить ввод в поле
типа CHAR (или VARCHAR, неважно) только цифр и сделать это на сервере
средствами sql.
Доку (EmbedSQL и DataDef) в направлении CHECK смотрел долго и упорно :)
BETWEEN и IN не подходят - они сравнивают
Alexander Kolokolzov [EMAIL PROTECTED] wrote in message news:[EMAIL
PROTECTED]
Можно, наверное, с EXISTS извратиться - создать табличку с одним полем, где
перечислить все цифры и сослаться на нее. Но нет ли способа попроще? Или тут
без udf никак? Или пойти и йаду выпить?
Если не Ya, то UDF.
Привет, Alexander!
Вы пишешь 15 февраля 2006:
[Sorry, skipped]
AK Можно, наверное, с EXISTS извратиться - создать табличку с одним полем,
AK где перечислить все цифры и сослаться на нее. Но нет ли способа попроще?
AK Или тут без udf никак? Или пойти и йаду выпить?
Раз уж речь зашла о
Horsun Vlad [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
без udf никак? Или пойти и йаду выпить?
field = '0' and field ':'
?
'' ?
Oleg LOA ...
С кэшем как я понял предложено мне разбираться? Типа сам нашёл - сам и
разбирайся :-):-):-),
Ну, если ты это уже когда-то правил, то тебе и карты в руки ;)
Но я всё-таки не верю, что это код кеша виноват, сорри...
Наш IO, конечно, далеко не оптимален и не умён, но
Hello, Oleg!
You wrote on Wed, 15 Feb 2006 12:37:07 +0300:
?? ручном вызове Unprepare, при разрушении компонента выполнившего
?? Prepare, при смене текста запроса.
??
?? Первый два случая понятны, но вот остальные - зачем?
OL остальные - это:
OL 3) разрушении компонента выполнившего Prepare
Dmitry Yemanov [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Офигеть.
Фразу дайте две!!! забыл :-):-):-):-)
http://www-306.ibm.com/software/data/db2/udb/db2express/download.html
Или это:
Пришла в орган, расположенный на плечах, такая мысль - разрешить ввод в
поле типа CHAR (или VARCHAR, неважно) только цифр и сделать это на сервере
средствами sql.
Интересная у тебя версия сервера какая-то. Только символьные типы
поддерживает. Самосбор?
Может это номер табельный :-),
Я тут уже писал - у меня один из последних снапшотов FB2.
Похоже, придется писать udf:
function CheckDigit(const field: string): boolean;
var
i: Integer;
begin
Result := False;
for i:=1 to length(field) do begin
if not (field[i] in [0..9]) then begin
Exit;
end;
Кастить...
Нет, лучше йаду выпить, у меня столько времени на проктологов нету :)
Alexander Kolokolzov пишет:
Пришла в орган, расположенный на плечах, такая мысль - разрешить ввод в поле
типа CHAR (или VARCHAR, неважно) только цифр и сделать это на сервере
средствами sql.
Интересная у тебя версия сервера какая-то. Только символьные типы
поддерживает. Самосбор?
Может
Oleg LOA ...
Horsun Vlad ...
Т.е. ты забираешь у винды под кеш птицы в 2 раза
больше памяти.
У меня ВСЯ БД влезает в память ;-), что с кэшем птицы что без. Она рахзмером
1.6 ГБ
1.6Г (бд) + 0.8Г (кеш птицы) наверное больше, чем 2Г (ОЗУ) ?
Я уж не говорю о нуждах ОС... В любом случае
sasha [EMAIL PROTECTED] wrote:
Оказывается что вызов EXECUTE PROCEDURE ... RETURNING VALUES
устанавливает ROW_COUNT в ноль
Вот пример:
У меня не устанавливает. Результат - две пятерки.
--
Дмитрий Еманов
Horsun Vlad wrote:
Так штааа - пользуйтесь правильно и будет вам 'щастье' ;-)
У меня прям щас весь отдел лежит. У админа звонит телефон. Мы,
ессно, слышим только его:
- Алё?
- Работает?
- (испуганно) Как? Работает? Почему работает?
:-D
--
Regards. Ded.
Horsun Vlad [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Ещё можешь пересобрать FB2 с FILE_FLAG_NO_BUFFERING - если
я прав, то тормоза будут и с малым, и с большим кешем (т.к. кеш ОС
не будет помогать), но с большим - меньше.
Да хорошая идея, пересобирать не буду - выключу
Я не вникал, как у нас сделан ROW_COUNT, но общее правило
(для всех известных мне серверов) гласит - переменные, описывающие
выполнение оператора (например @@ERROR, @@ROWS_AFFECTED,
@@FETCH_STATUS в T-SQL), имеют валидное значение только сразу
после этого оператора.
Т.е. ты хочешь сказать
sasha ...
Я не вникал, как у нас сделан ROW_COUNT, но общее правило
(для всех известных мне серверов) гласит - переменные, описывающие
выполнение оператора (например @@ERROR, @@ROWS_AFFECTED,
@@FETCH_STATUS в T-SQL), имеют валидное значение только сразу
после этого оператора.
sasha [EMAIL PROTECTED] wrote:
Вопрос: можно ли на такое поведение расчитывать и в дальнейшем?
В двойке - можно. Вообще - см. правило Влада.
Лично по мне, EXECUTE PROCEDURE должен устанавливать ROW_COUNT в суммарное
кол-во вставленных, измененных и удаленных строк внутри оной процедуры
FREE Lite Version of SR UDF Library (70 UDFs) is available for download
now!
http://www.srmaster.com
Alexander Kolokolzov пишет:
Я тут уже писал - у меня один из последних снапшотов FB2.
Похоже, придется писать udf:
function CheckDigit(const field: string): boolean;
Лучше прикрути udf с регулярными выражениями (типа matchesRegex), и
будет тебе счастье :)
--
wbr, ps
ps-at-azs-ru
Лучше прикрути udf с регулярными выражениями (типа matchesRegex), и
будет тебе счастье :)
Из такой пушки, да по такому воробью? :) Хотя на будущее, мож, и сгодится.
Ссылку не дашь?
41 matches
Mail list logo
