Ну почему же странный?
но он переменную $b в данном случае, никак не использует
$b = 'dd';
$obj->dd;$b = 'dd';
$obj->$b;melkij@melkij:~$ php -d opcache.enable_cli=on -d opcache.opt_debug_level=0x10000 /tmp/op.php
$_main: ; (lines=8, args=0, vars=2, tmps=6)
; (before optimizer)
; /tmp/op.php:1-7
L0 (2): NOP
L1 (5): V3 = NEW 0 string("a")
L2 (5): DO_FCALL
L3 (5): ASSIGN CV0($obj) V3
L4 (6): V6 = ASSIGN CV1($b) string("dd")
L5 (6): T7 = FETCH_OBJ_R CV0($obj) V6
L6 (6): FREE T7
L7 (7): RETURN int(1)
PHP Notice: Undefined property: a::$dd in /tmp/op.php on line 6
melkij@melkij:~$ php -d opcache.enable_cli=on -d opcache.opt_debug_level=0x20000 /tmp/op.php
$_main: ; (lines=7, args=0, vars=2, tmps=2)
; (after optimizer)
; /tmp/op.php:1-7
L0 (5): V2 = NEW 0 string("a")
L1 (5): DO_FCALL
L2 (5): ASSIGN CV0($obj) V2
L3 (6): V3 = ASSIGN CV1($b) string("dd")
L4 (6): T2 = FETCH_OBJ_R CV0($obj) string("dd")
L5 (6): FREE T2
L6 (7): RETURN int(1)
PHP Notice: Undefined property: a::$dd in /tmp/op.php on line 6For backwards-compatibility reasons, we allow an expression that's just a function call to be written without parens.
В первом случае убедитесь, что -z включено и попробуйте -Z 9
Во втором случае попробуйте наоборот -Z 1, чтобы уменьшить нагрузку на CPU
Транзакции выполняются полностью последовательно на этом уровне
create table foo (i int);
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
start transaction;
select * from foo where i != 5;
insert into foo values (5);
-- до коммита сделайте со второй консоли такие же запросы начиная с set transaction, затем коммит в обеих
-- при корректной реализации второй коммит разрешён не должен быть.
commit;
Почему вы смотрите только минимальную дискретность? Посмотрите ещё минимальные и максимальные значения, а так же требуемые для этого размеры структуры данных. Это всё имеет свою цену. Вам необходимо место для хранения (maxvalue - minvalue)/дискретность. Чем меньше дискретность - тем вам нужно больше ресурсов для хранения, чтения/записи и обработки. Это вполне очевидно.
В оракле timestamp - 11 или 13 байт.
В postgresql - 8 байт.
mysql - 4 байта + до 3 байт на хранение долей секунды (вы по "timestamp 4 байта" уже догадались о проблеме 2038?)
Итого в сырой ёмкости записанных данных один и тот же набор данных займёт в оракле в 1,5 раза больше места чем в postgresql.
Действительно надо сделать одинаково плохо всем увеличив размер данных? А если мы работаем с астрономами и им этот крохотный диапазон с 4713 BC по 294276 AD бесполезен полностью? Увеличим и эти даты тоже? Ну и пусть каждый таймштамп будет в килобайт размером, зато его же хватит всем.