ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Postgres оптимизация вопроса?
25 сообщений из 35, страница 1 из 2
  1  все
Postgres оптимизация вопроса?
    #38870942
DoomUnit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DoomUnit
Участник
PostgreSQL 9.3.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4), 64-bit

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
/*------ 04.02.2015 8:40:12 --------*/

EXPLAIN ANALYZE   SELECT  EXTRACT(EPOCH FROM   "F_Date"),
				"F_ConvertedValue",
				"F_TagName_ID" FROM
				"SC_Tag"."T_TagData"
				where
                "F_Date" > (localtimestamp - interval'1 hour') and
				"F_TagName_ID" in (73,72,39,64,76,75) 
				
				ORDER BY "F_Date" asc;;

/* Результат : "LOG:  duration: 11276.442 ms  statement: EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75) ORDER BY "F_Date" asc;;

возвращено записей: 7 (выполнено: 11,279 с; всего: 11,279 с)" */



/*------ 04.02.2015 8:49:52 --------*/

EXPLAIN ANALYZE   SELECT  EXTRACT(EPOCH FROM   "F_Date"),
				"F_ConvertedValue",
				"F_TagName_ID" FROM
				"SC_Tag"."T_TagData"
				where
                "F_Date" > (localtimestamp - interval'1 hour') and
				"F_TagName_ID" in (73,72,39,64,76,75) 
				
				--ORDER BY "F_Date" asc;;

/* Результат : "LOG:  duration: 9359.324 ms  statement: EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75)

возвращено записей: 4 (выполнено: 9,360 с; всего: 9,375 с)" */






это вообще кошмарно. может имеет смысл сортировать уже на клиенте али может какие другие соображения будут?
...
Рейтинг: 0 / 0
04.02.2015, 07:00
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38870964
Лопата
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лопата
Участник
DoomUnitPostgreSQL 9.3.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4), 64-bit

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
/*------ 04.02.2015 8:40:12 --------*/

EXPLAIN ANALYZE   SELECT  EXTRACT(EPOCH FROM   "F_Date"),
				"F_ConvertedValue",
				"F_TagName_ID" FROM
				"SC_Tag"."T_TagData"
				where
                "F_Date" > (localtimestamp - interval'1 hour') and
				"F_TagName_ID" in (73,72,39,64,76,75) 
				
				ORDER BY "F_Date" asc;;

/* Результат : "LOG:  duration: 11276.442 ms  statement: EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75) ORDER BY "F_Date" asc;;

возвращено записей: 7 (выполнено: 11,279 с; всего: 11,279 с)" */



/*------ 04.02.2015 8:49:52 --------*/

EXPLAIN ANALYZE   SELECT  EXTRACT(EPOCH FROM   "F_Date"),
				"F_ConvertedValue",
				"F_TagName_ID" FROM
				"SC_Tag"."T_TagData"
				where
                "F_Date" > (localtimestamp - interval'1 hour') and
				"F_TagName_ID" in (73,72,39,64,76,75) 
				
				--ORDER BY "F_Date" asc;;

/* Результат : "LOG:  duration: 9359.324 ms  statement: EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75)

возвращено записей: 4 (выполнено: 9,360 с; всего: 9,375 с)" */






это вообще кошмарно. может имеет смысл сортировать уже на клиенте али может какие другие соображения будут?

кошмарно быт таким negsv vskfrjv, и не видеть 29лямов rows removed by filter в приведенном собою же плане.

я так скажу -- "уж лучше на клиенте фильтровать " убив перед этим клиента 30 лямами записей, положив его наконец лицом вниз, и всыпав розог.


кстати, какого хера вы текст картинкой вставляете ? чтобы вас труднее было внего носом ткнуть ? так я и так скажу что вы pfghtltkmysq gblfhfc

убивать убивать убивать dfnys[ gblfhfcjd
...
Рейтинг: 0 / 0
04.02.2015, 08:05
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38870990
rovan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rovan
Гость
DoomUnit, оба запроса на горячую запускались? Т.е. данные уже подгрузились в буферы? Как-то подозрительно выглядит двухсекундная сортировка менее, чем 10 строк (две секунды смотрю просто по разнице 11 против 9).
...
Рейтинг: 0 / 0
04.02.2015, 08:37
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38870994
DoomUnit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DoomUnit
Участник
ну сервачок изрядно грузится просто. вот и ищу способы оптимизации. а как прибить 30 млн строк то?
...
Рейтинг: 0 / 0
04.02.2015, 08:44
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871002
anon2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anon2
Гость
rovan, т.е вас только сортировка смутила? ;)
...
Рейтинг: 0 / 0
04.02.2015, 09:00
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871007
DoomUnit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DoomUnit
Участник
так а как переписать запрос чтобы он быстрее работал?
...
Рейтинг: 0 / 0
04.02.2015, 09:08
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871058
/\/\/\/\/\/\
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
/\/\/\/\/\/\
Гость
DoomUnit,

Никак. Этот запрос просто прекрасен.
...
Рейтинг: 0 / 0
04.02.2015, 09:49
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871070
DoomUnit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DoomUnit
Участник
/\/\/\/\/\/\,

...
Рейтинг: 0 / 0
04.02.2015, 10:02
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871071
DoomUnit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DoomUnit
Участник
ой млин дал жару с сарказмом((
...
Рейтинг: 0 / 0
04.02.2015, 10:02
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871072
Лопата
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лопата
Участник
DoomUnitтак а как переписать запрос чтобы он быстрее работал?

Use The Index, Luke!
...
Рейтинг: 0 / 0
04.02.2015, 10:03
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871074
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
DoomUnit,

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


--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
04.02.2015, 10:04
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871075
Лопата
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лопата
Участник
DoomUnitой млин дал жару с сарказмом((вот всё у вас так, -- со сраказмом

-- "сказочный, сказочный далпайоп"(тм)
...
Рейтинг: 0 / 0
04.02.2015, 10:05
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871091
DoomUnit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DoomUnit
Участник
Создание индекса в большой таблице может занять длительное время. По умолчанию, PostgreSQL позволяет читать (выбирать) из таблицы, параллельно с созданием индекса, но блокирует запись (вставку, обновление и удаление) до конца построения индекса. В производственной среде это часто неприемлемо. Можно позволить запись параллельно с созданием индекса, но есть несколько предостережений, о которых надо быть в курсе - для получения дополнительной информации см. создание индексов без блокировки .

После того, как индекс будет создан, система должна поддерживать ее синхронизированным с таблицей. Это добавляет дополнительные расходы на операции с данными. Поэтому индексы, которые редко или никогда не используются в запросах должны быть удалены.

Получается динамически создавть индексы для данных последних дней не получится?
...
Рейтинг: 0 / 0
04.02.2015, 10:14
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871094
Добрый Э - Эх
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Добрый Э - Эх
Гость
DoomUnit,

не хочешь индексы, используй секционирование
...
Рейтинг: 0 / 0
04.02.2015, 10:19
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871112
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
DoomUnitСоздание индекса в большой таблице может занять длительное время. По умолчанию, PostgreSQL позволяет читать (выбирать) из таблицы, параллельно с созданием индекса, но блокирует запись (вставку, обновление и удаление) до конца построения индекса. В производственной среде это часто неприемлемо. Можно позволить запись параллельно с созданием индекса, но есть несколько предостережений, о которых надо быть в курсе - для получения дополнительной информации см. создание индексов без блокировки .

После того, как индекс будет создан, система должна поддерживать ее синхронизированным с таблицей. Это добавляет дополнительные расходы на операции с данными. Поэтому индексы, которые редко или никогда не используются в запросах должны быть удалены.

Получается динамически создавть индексы для данных последних дней не получится?

Создание индекса на современном Postgresql (с CONCURRENTLY) не блокирует вообще ничего.

Если запрос выполняется редко - то какой смысл его оптимизировать... пусть медленно работает.
Если же надо чтобы он работал быстрее - без правильных индексов вы его никак не ускорите. Точка.
Или/или.

PS: динамическое создание индексов штука не особо осмысленная в 99% случаев.
...
Рейтинг: 0 / 0
04.02.2015, 10:38
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871120
DoomUnit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DoomUnit
Участник
тогда видится такое решение - создание какой то буферной таблицы с ротацией в неделю
...
Рейтинг: 0 / 0
04.02.2015, 10:45
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871144
anon2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anon2
Гость
DoomUnit ваша проблема в незнании основ.
Просто создайте индекс для F_Date
...
Рейтинг: 0 / 0
04.02.2015, 11:24
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871156
rovan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rovan
Гость
anon2rovan, т.е вас только сортировка смутила? ;)
Разные вещи смутили меня, но вопрос-то был сформулирован именно про сортировку:)

ТССоздание индекса в большой таблице может занять длительное время. По умолчанию, PostgreSQL позволяет читать (выбирать) из таблицы, параллельно с созданием индекса, но блокирует запись (вставку, обновление и удаление) до конца построения индекса. В производственной среде это часто неприемлемо. Можно позволить запись параллельно с созданием индекса, но есть несколько предостережений, о которых надо быть в курсе - для получения дополнительной информации см. создание индексов без блокировки .
Про CONCURRENTLY уже сказали.
авторПосле того, как индекс будет создан, система должна поддерживать ее синхронизированным с таблицей. Это добавляет дополнительные расходы на операции с данными. Поэтому индексы, которые редко или никогда не используются в запросах должны быть удалены.

Реальные задержки замерял? Ну, там, с индексом, без индекса. Полагаю, что нет.

МаксимЕсли запрос выполняется редко - то какой смысл его оптимизировать... пусть медленно работает.
Если же надо чтобы он работал быстрее - без правильных индексов вы его никак не ускорите. Точка.

Слушай опытных людей, ТС, и не занимайся фигнёй. "Фигня" в данном конкретном случае - это "буферные таблицы" и прочие высосанные из пальца решения.
...
Рейтинг: 0 / 0
04.02.2015, 11:33
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871165
DoomUnit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DoomUnit
Участник
нет но вот партицирование оно же секционирование как я понимаю то что нужно. а создание индексов и удаление динамически в моем случае не очень понимаю. создание с помощью секцинирования таблицы последних 2 недель вродь как самый оптимальный вариант. конечно можно секции на каждый месяц делать, но трудности возникнут при переходах на другой месяц. а вот секция последних 2х недель то что нужно
...
Рейтинг: 0 / 0
04.02.2015, 11:38
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871179
Лопата
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лопата
Участник
DoomUnitнет но вот партицирование оно же секционирование как я понимаю то что нужно. а создание индексов и удаление динамически в моем случае не очень понимаю. создание с помощью секцинирования таблицы последних 2 недель вродь как самый оптимальный вариант. конечно можно секции на каждый месяц делать, но трудности возникнут при переходах на другой месяц. а вот секция последних 2х недель то что нужно

запредельно сказочный долбойоб.
...
Рейтинг: 0 / 0
04.02.2015, 11:46
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871181
rovan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rovan
Гость
DoomUnit,

зачем тебе динамически создавать и удалять индекс?
Вероисповедание запрещает создать его и оставить нетронутым?
...
Рейтинг: 0 / 0
04.02.2015, 11:47
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871213
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
rovanDoomUnit, оба запроса на горячую запускались? Т.е. данные уже подгрузились в буферы? Как-то подозрительно выглядит двухсекундная сортировка менее, чем 10 строк (две секунды смотрю просто по разнице 11 против 9).
сортировка занимает положенные 0.4 милисекунды.
...
Рейтинг: 0 / 0
04.02.2015, 12:12
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871270
DoomUnit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DoomUnit
Участник
так и как мне в данной ситуации создавать индекс? при добавлениии вешать индекс на время? не очень понимаю
...
Рейтинг: 0 / 0
04.02.2015, 12:47
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871292
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
DoomUnit,

вам же написали... для начала создать индекс по F_Date
если недостаточно ускорится попробовать создать индекс по (F_TagName_ID, F_Date)
если ни то ни другое не поможет то прислать explain analyze в обоих вариантах и можно будет подумать дальше.


--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
04.02.2015, 13:00
| Ответить | Цитировать | Написать  
Postgres оптимизация вопроса?
    #38871313
DoomUnit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DoomUnit
Участник
и это не повредит боевой базе? чет думаю сча разбиение попробовать на тесте. все равно индексы в 29 млн записей сделают не много. нужно резать базу
...
Рейтинг: 0 / 0
04.02.2015, 13:08
| Ответить | Цитировать | Написать  
25 сообщений из 35, страница 1 из 2
  1  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Postgres оптимизация вопроса?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=38871112&tid=1998196]:
 0ms
get settings:
 7ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 213ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 81ms
get tp. blocked users:
 1ms
others: 205ms
total:  540ms
созд. / загр.: 540ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]