XN
а этот номер привязан только к компании 49
Size: a a a
2020 August 04
YS
тут кстати ошибка если убрать фильтр по company_id из самого вложенного запроса
Да, если. В Вашем примере запроса он есть. ;)
Добавьте PARTITION BY, если этого фильтра нет, конечно.
Добавьте PARTITION BY, если этого фильтра нет, конечно.
XN
Yaroslav Schekin
Да, если. В Вашем примере запроса он есть. ;)
Добавьте PARTITION BY, если этого фильтра нет, конечно.
Добавьте PARTITION BY, если этого фильтра нет, конечно.
да, согласен, немного не корректно написал запрос в начале)
XN
first_value(number) OVER (PARTITION BY company_id ORDER BY created_at DESC) AS last_number
так правильно?
так правильно?
YS
first_value(number) OVER (PARTITION BY company_id ORDER BY created_at DESC) AS last_number
так правильно?
так правильно?
С виду, да. Да и Вы же всё равно тестировать будете. :)
XN
Yaroslav Schekin
С виду, да. Да и Вы же всё равно тестировать будете. :)
спасибо)
YS
спасибо)
Да не за что! ;)
Кроме упомянутых стандартных способов есть ещё вот такая штука, кстати (если подобное часто нужно и хочется, чтобы запросы были попроще / поэффективнее): https://wiki.postgresql.org/wiki/First/last_(aggregate)
С ней тот же запрос будет выглядеть как-то так:
Короче/понятнее, IMHO.
Кроме упомянутых стандартных способов есть ещё вот такая штука, кстати (если подобное часто нужно и хочется, чтобы запросы были попроще / поэффективнее): https://wiki.postgresql.org/wiki/First/last_(aggregate)
С ней тот же запрос будет выглядеть как-то так:
SELECT COUNT(*) AS cnt, company_id, first(number ORDER BY created_at DESC) AS last_number
FROM "order"
WHERE status = 20 AND company_id = 119
GROUP BY company_id;
Короче/понятнее, IMHO.
XN
Yaroslav Schekin
Да не за что! ;)
Кроме упомянутых стандартных способов есть ещё вот такая штука, кстати (если подобное часто нужно и хочется, чтобы запросы были попроще / поэффективнее): https://wiki.postgresql.org/wiki/First/last_(aggregate)
С ней тот же запрос будет выглядеть как-то так:
Короче/понятнее, IMHO.
Кроме упомянутых стандартных способов есть ещё вот такая штука, кстати (если подобное часто нужно и хочется, чтобы запросы были попроще / поэффективнее): https://wiki.postgresql.org/wiki/First/last_(aggregate)
С ней тот же запрос будет выглядеть как-то так:
SELECT COUNT(*) AS cnt, company_id, first(number ORDER BY created_at DESC) AS last_number
FROM "order"
WHERE status = 20 AND company_id = 119
GROUP BY company_id;
Короче/понятнее, IMHO.
еще есть вопрос, при какой цене стоит задумываться об оптимизации?) я про explain
l
еще есть вопрос, при какой цене стоит задумываться об оптимизации?) я про explain
Когда запрос не устраивает по времени выполнения
XN
Когда запрос не устраивает по времени выполнения
логично)
YS
еще есть вопрос, при какой цене стоит задумываться об оптимизации?) я про explain
Вы про cost-ы в EXPLAIN? Они вообще ничего не значат, это "попугаи".
А так — я лично за KISS / when it hurts. ;)
А так — я лично за KISS / when it hurts. ;)
XN
Yaroslav Schekin
Да не за что! ;)
Кроме упомянутых стандартных способов есть ещё вот такая штука, кстати (если подобное часто нужно и хочется, чтобы запросы были попроще / поэффективнее): https://wiki.postgresql.org/wiki/First/last_(aggregate)
С ней тот же запрос будет выглядеть как-то так:
Короче/понятнее, IMHO.
Кроме упомянутых стандартных способов есть ещё вот такая штука, кстати (если подобное часто нужно и хочется, чтобы запросы были попроще / поэффективнее): https://wiki.postgresql.org/wiki/First/last_(aggregate)
С ней тот же запрос будет выглядеть как-то так:
SELECT COUNT(*) AS cnt, company_id, first(number ORDER BY created_at DESC) AS last_number
FROM "order"
WHERE status = 20 AND company_id = 119
GROUP BY company_id;
Короче/понятнее, IMHO.
не находит first
XN
ERROR: function first(character varying) does not exist
XN
PostgreSQL 12.3 (Ubuntu 12.3-1.pgdg18.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit
YS
не находит first
Потому что Вы её не создали, наверное? Вы ссылку прочитали, а? ;)
IC
Yaroslav Schekin
Вы про cost-ы в EXPLAIN? Они вообще ничего не значат, это "попугаи".
А так — я лично за KISS / when it hurts. ;)
А так — я лично за KISS / when it hurts. ;)
Я не так долго и не очень много работаю с PostgreSQL, но косты меня сильно удивляют после MS. Там хоть как-то ориентироваться можно.
YS
Я не так долго и не очень много работаю с PostgreSQL, но косты меня сильно удивляют после MS. Там хоть как-то ориентироваться можно.
"Как-то" можно и здесь. Но сам принцип в MS SQL ровно тот же — это "попугаи".
IC
Принцип - да. Но вот в вышеописанной ситуации с подзапросом и джойном косты отличались процентов на 30%, а по факту минута против 1 часа +. Попугаи МС-а кажутся более породистыми и предсказуемыми 😁
YS
Принцип - да. Но вот в вышеописанной ситуации с подзапросом и джойном косты отличались процентов на 30%, а по факту минута против 1 часа +. Попугаи МС-а кажутся более породистыми и предсказуемыми 😁
А оценки rows были правильные (хоть примерно)? Если нет — то и cost-ы "поедут", конечно (это в любом планировщике).
И, во-вторых, правильные настройки (tuning) costs в PostgreSQL (под "железо" и нагрузку) — это Ваша проблема (но и возможность), в отличие от. ;)
См. http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
И, во-вторых, правильные настройки (tuning) costs в PostgreSQL (под "железо" и нагрузку) — это Ваша проблема (но и возможность), в отличие от. ;)
См. http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
IC
Да, статистика на месте, оценки правильные. Настройки, к счастью, не моя проблема, сервера у клиента, админы там же. Но склонен согласиться, так как на дев и прод средах попугаи сильно различаются при схожих данных. При случае надо будет подискутировать с админами.