Re: [pgsql-ru-general] Re[2]: [pgsql-ru-general] Re[2]: [pgsql-ru-general] Re: [pgsql-ru-general] порядок вставки
| От | Andrey Asyakin |
|---|---|
| Тема | Re: [pgsql-ru-general] Re[2]: [pgsql-ru-general] Re[2]: [pgsql-ru-general] Re: [pgsql-ru-general] порядок вставки |
| Дата | |
| Msg-id | CAFnzpOVDq58Zh9hzWDaJLo_39OAyqsaReb82OU=m9ZLeOFz-sQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re[2]: [pgsql-ru-general] Re: [pgsql-ru-general] порядок вставки (Иван Фролков <ifrol2001@mail.ru>) |
| Ответы |
Re: Re: [pgsql-ru-general] Re[2]: [pgsql-ru-general] Re[2]: [pgsql-ru-general] Re: [pgsql-ru-general] порядок вставки
|
| Список | pgsql-ru-general |
а SELECT * FROM "with_results" может отличаться в порядке?
Надо бы смотреть доку по WITH.
Можно подстраховаться,
Можно подстраховаться,
with a ( select 1 n, ...),
b ( select 2 n, ...),
c ( ... union all ...)
insert into t(z, x) select z, x from c order by n
Я по другому понял вопрос, может ли в запросе insert .. select записи вставиться не в том порядке, в котором их возвращает select. Насколько я понял, нет, потому что для инсерта не создается какого то особого плана, план создается для селекта, просто вместо отправки клиенту записи пишутся в таблицу.
что то я не пойму насчет WITH, зачем он? если формируешь сам, чем не устраивает
INSERT TO "billing_log"
("rollback", "sum", "txnname")
VALUES
(TRUE, -123, 'заказ 342'),
(FALSE, 10, 'заказ 342')
INSERT TO "billing_log"
("rollback", "sum", "txnname")
VALUES
(TRUE, -123, 'заказ 342'),
(FALSE, 10, 'заказ 342')
20 октября 2015 г., 12:39 пользователь Dmitry E. Oboukhov <unera@debian.org> написал:
>> в таблицу записываем произошедшие одно за другим события.
>> SERIAL в первичном ключе таким образом определяет какое событие было
>> раньше какое позже (таймстемп тоже есть, но он больше декоративный)
>> поэтому порядок INSERT'ов мне важен.
> Вы поступаете неправильно, и вот почему - во-первых, такие вставки могут идти параллельно, и тогда порядок становится совсем уж странным; во-вторых, порядок вставки при insert действительно не определен (при каком-то другом объеме данных и положении звезд сервер может изменить план и порядок будет совсем иным); и то, что оно иногда (а то и практически всегда) может работать так, как вам надо - не более чем совпадение. Я бы набрался наглости и посоветовал бы либо сделать timestamp не декоративным, либо ввести какой-то свое значение для упорядочивания).
про параллельные вставки я все понимаю.
те что идут параллельно - они (так устроена система) не предъявляют
требований к тому что одна может записаться раньше другой
основной поток делает один INSERT и все
но вот есть конкретно случаи, когда требуется сохранить
последовательность и соответственно там требуется атомарно записать
две записи в БД.
я в соседнем письме описал задачу более подробно--
. ''`. Dmitry E. Oboukhov
: :’ : email: unera@debian.org jabber://UNera@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEAREDAAYFAlYmC9IACgkQq4wAz/jiZTe1ugCgxCvt2YvBgyXAjbB0CFoLNNa7
wyUAn2weG+s6/AzeDJxDSZvhCG+aEy9O
=QRLu
-----END PGP SIGNATURE-----
В списке pgsql-ru-general по дате отправления: