Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Postgres оптимизация вопроса? / 25 сообщений из 35, страница 1 из 2
  1  все
04.02.2015, 07:00
    #38870942
DoomUnit
DoomUnit
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Postgres оптимизация вопроса?
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, 08:05
    #38870964
Лопата
Лопата
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Postgres оптимизация вопроса?
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:37
    #38870990
rovan
rovan
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Postgres оптимизация вопроса?
DoomUnit, оба запроса на горячую запускались? Т.е. данные уже подгрузились в буферы? Как-то подозрительно выглядит двухсекундная сортировка менее, чем 10 строк (две секунды смотрю просто по разнице 11 против 9).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
04.02.2015, 08:44
    #38870994
DoomUnit
DoomUnit
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Postgres оптимизация вопроса?
ну сервачок изрядно грузится просто. вот и ищу способы оптимизации. а как прибить 30 млн строк то?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
04.02.2015, 09:00
    #38871002
anon2
anon2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Postgres оптимизация вопроса?
rovan, т.е вас только сортировка смутила? ;)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
04.02.2015, 09:08
    #38871007
DoomUnit
DoomUnit
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Postgres оптимизация вопроса?
так а как переписать запрос чтобы он быстрее работал?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
04.02.2015, 09:49
    #38871058
/\/\/\/\/\/\
/\/\/\/\/\/\
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Postgres оптимизация вопроса?
DoomUnit,

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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