ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / опять оптимизация запроса
18 сообщений из 43, страница 2 из 2
  2  все
опять оптимизация запроса
    #34257120
akimovp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
akimovp
Гость
Andrey DaeronБыло бы очень интересно посмотреть на результат такого перехода, на сколько стало лучше и за счет чего. Впрочем на ответ из мейллиста Постгреса тоже.
Кстати, никто не посоветует нормальной тулзы для мигрирования, переноса данных с Postgres на другие базы.
...
Рейтинг: 0 / 0
15.01.2007, 21:31
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34257765
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
akimovp Andrey DaeronБыло бы очень интересно посмотреть на результат такого перехода, на сколько стало лучше и за счет чего. Впрочем на ответ из мейллиста Постгреса тоже.
Кстати, никто не посоветует нормальной тулзы для мигрирования, переноса данных с Postgres на другие базы.
EMSовский export - может поможет.
...
Рейтинг: 0 / 0
16.01.2007, 10:36
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34257846
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
akimovp LeXa NalBatcreate index dealerpayment_agent_paymentid on dealerpayment ( agent, paymentid );Такой индекс pg начинает использовать. Но результат только немного лучше первоначального. Bitmap Heap Scan on dealerpayment comissions1_ - занимает очень много времени. Похоже что он этот индекс только для фильтра agent='xxx' использует pg , а для comissions1_.paymentid=payment0_.id не использует.Что вы имеете в виду? Как индекс может использоваться при соединении двух наборов?

При подготовке набора comissions1_ методом bitmapscan индекс dealerpayment_agent_paymentid используется только для фильтрации по agent. Поэтому для выполнения последующего mergejoin требуется sort. Попробуйте выключить bitmapscan: set enable_bitmapscan to off.
...
Рейтинг: 0 / 0
16.01.2007, 10:59
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34258179
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
Кста, есть еще вариант - примутить данные, что бы они не содержали конфиденциальных данных и выложить дамп архыва за пару месяцев, что бы можно было поковыряться большему кол-ву народу.
...
Рейтинг: 0 / 0
16.01.2007, 12:09
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34259022
akimovp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
akimovp
Гость
Andrey Daeron akimovp Andrey DaeronБыло бы очень интересно посмотреть на результат такого перехода, на сколько стало лучше и за счет чего. Впрочем на ответ из мейллиста Постгреса тоже.
Кстати, никто не посоветует нормальной тулзы для мигрирования, переноса данных с Postgres на другие базы.
EMSовский export - может поможет.

А для линукса что-нить посоветуете?
...
Рейтинг: 0 / 0
16.01.2007, 15:06
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34259097
akimovp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
akimovp
Гость
LeXa NalBat

При подготовке набора comissions1_ методом bitmapscan индекс dealerpayment_agent_paymentid используется только для фильтрации по agent. Поэтому для выполнения последующего mergejoin требуется sort. Попробуйте выключить bitmapscan: set enable_bitmapscan to off.

Сегодня экспериментировал с
Merge Join vs. Hash Join никакой разницы не заметил.
...
Рейтинг: 0 / 0
16.01.2007, 15:28
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34259356
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
akimovpСегодня экспериментировал с Merge Join vs. Hash Join никакой разницы не заметил.Опубликуйте пожалуйста выдачу explain analyze.
...
Рейтинг: 0 / 0
16.01.2007, 16:37
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34259447
akimovp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
akimovp
Гость
LeXa NalBat akimovpСегодня экспериментировал с Merge Join vs. Hash Join никакой разницы не заметил.Опубликуйте пожалуйста выдачу explain analyze.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Group  (cost= 51979 . 55 .. 53684 . 28  rows= 96359  width= 8 ) (actual time= 22144 . 041 .. 22778 . 540  rows= 30  loops= 1 )
   ->  Sort  (cost= 51979 . 55 .. 52225 . 06  rows= 98204  width= 8 ) (actual time= 22144 . 029 .. 22482 . 904  rows= 89988  loops= 1 )
         Sort Key: date_part('year'::text, payment0_.datetime), date_part('month'::text, payment0_.datetime), date_part('day'::text, payment0_.datetime)
         ->  Hash Join  (cost= 7478 . 17 .. 43836 . 72  rows= 98204  width= 8 ) (actual time= 11682 . 493 .. 20793 . 541  rows= 89988  loops= 1 )
               Hash Cond: ("outer".paymentid = "inner".id)
               ->  Bitmap Heap Scan on dealerpayment comissions1_  (cost= 2709 . 03 .. 30438 . 86  rows= 394866  width= 8 ) (actual time= 1795 . 884 .. 16283 . 348  rows= 356908  loops= 1 )
                     Recheck Cond: ((agent)::text = 'pinpay'::text)
                     ->  Bitmap Index Scan on dealerpayment_agent  (cost= 0 . 00 .. 2709 . 03  rows= 394866  width= 0 ) (actual time= 1745 . 456 .. 1745 .456rows= 357594  loops= 1 )
                           Index Cond: ((agent)::text = 'pinpay'::text)
               ->  Hash  (cost= 4528 . 24 .. 4528 . 24  rows= 96359  width= 16 ) (actual time= 2320 . 976 .. 2320 . 976  rows= 90622  loops= 1 )
                     ->  Index Scan using payment_datetime on payment payment0_  (cost= 0 . 00 .. 4528 . 24  rows= 96359  width= 16 ) (actual time= 201 . 705 .. 1952 . 764  rows= 90622  loops= 1 )
                           Index Cond: ((datetime > '2006-12-01 00:00:00'::timestamp without time zone) AND (datetime < '2006-12-31 00:00:00'::timestamp without time zone))
 Total runtime:  22787 . 827  ms( 13  rows)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Group  (cost= 65689 . 87 .. 67394 . 67  rows= 96368  width= 8 ) (actual time= 19360 . 042 .. 19944 . 381  rows= 30  loops= 1 )
   ->  Sort  (cost= 65689 . 87 .. 65935 . 38  rows= 98204  width= 8 ) (actual time= 19360 . 032 .. 19654 . 120  rows= 89988  loops= 1 )
         Sort Key: date_part('year'::text, payment0_.datetime), date_part('month'::text, payment0_.datetime), date_part('day'::text, payment0_.datetime)
         ->  Merge Join  (cost= 12505 . 85 .. 57547 . 04  rows= 98204  width= 8 ) (actual time= 15571 . 548 .. 18334 . 228  rows= 89988  loops= 1 )
               Merge Cond: ("outer".paymentid = "inner".id)
               ->  Index Scan using dealerpayment_pid on dealerpayment comissions1_  (cost= 0 . 00 .. 41844 . 54  rows= 394866  width= 8 ) (actual time= 15 . 634 .. 11923 . 316  rows= 288189  loops= 1 )
                     Filter: ((agent)::text = 'pinpay'::text)
               ->  Sort  (cost= 12505 . 85 .. 12746 . 77  rows= 96368  width= 16 ) (actual time= 4029 . 828 .. 4416 . 376  rows= 90622  loops= 1 )
                     Sort Key: payment0_.id
                     ->  Index Scan using payment_datetime on payment payment0_  (cost= 0 . 00 .. 4528 . 38  rows= 96368  width= 16 ) (actual time= 92 . 959 .. 3354 . 626  rows= 90622  loops= 1 )
                           Index Cond: ((datetime > '2006-12-01 00:00:00'::timestamp without time zone) AND (datetime < '2006-12-31 00:00:00'::timestamp without time zone))
 Total runtime:  19955 . 360  ms
...
Рейтинг: 0 / 0
16.01.2007, 16:59
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34259571
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
akimovp
Код: plaintext
1.
2.
3.
               ->  Bitmap Heap Scan on dealerpayment comissions1_  (cost= 2709 . 03 .. 30438 . 86  rows= 394866  width= 8 ) (actual time= 1795 . 884 .. 16283 . 348  rows= 356908  loops= 1 )
                     Recheck Cond: ((agent)::text = 'pinpay'::text)
                     ->  Bitmap Index Scan on dealerpayment_agent  (cost= 0 . 00 .. 2709 . 03  rows= 394866  width= 0 ) (actual time= 1745 . 456 .. 1745 .456rows= 357594  loops= 1 )
                           Index Cond: ((agent)::text = 'pinpay'::text)
Код: plaintext
1.
               ->  Index Scan using dealerpayment_pid on dealerpayment comissions1_  (cost= 0 . 00 .. 41844 . 54  rows= 394866  width= 8 ) (actual time= 15 . 634 .. 11923 . 316  rows= 288189  loops= 1 )
                     Filter: ((agent)::text = 'pinpay'::text)
В этих планах не используется индекс по dealerpayment(agent,paymentid). Попробуйте добиться такого плана.
...
Рейтинг: 0 / 0
16.01.2007, 17:35
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34259960
akimovp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
akimovp
Гость
LeXa NalBat akimovp
Код: plaintext
1.
2.
3.
               ->  Bitmap Heap Scan on dealerpayment comissions1_  (cost= 2709 . 03 .. 30438 . 86  rows= 394866  width= 8 ) (actual time= 1795 . 884 .. 16283 . 348  rows= 356908  loops= 1 )
                     Recheck Cond: ((agent)::text = 'pinpay'::text)
                     ->  Bitmap Index Scan on dealerpayment_agent  (cost= 0 . 00 .. 2709 . 03  rows= 394866  width= 0 ) (actual time= 1745 . 456 .. 1745 .456rows= 357594  loops= 1 )
                           Index Cond: ((agent)::text = 'pinpay'::text)
Код: plaintext
1.
               ->  Index Scan using dealerpayment_pid on dealerpayment comissions1_  (cost= 0 . 00 .. 41844 . 54  rows= 394866  width= 8 ) (actual time= 15 . 634 .. 11923 . 316  rows= 288189  loops= 1 )
                     Filter: ((agent)::text = 'pinpay'::text)
В этих планах не используется индекс по dealerpayment(agent,paymentid). Попробуйте добиться такого плана.
Я не знаю как заставить Postgresql его использовать в этом SQL.
...
Рейтинг: 0 / 0
16.01.2007, 20:09
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34260581
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
akimovp LeXa NalBatВ этих планах не используется индекс по dealerpayment(agent,paymentid). Попробуйте добиться такого плана.Я не знаю как заставить Postgresql его использовать в этом SQL.Удалите все индексы на таблицу dealerpayment кроме (agent,paymentid). Далее с помощью команд set enable_... to off/on.
...
Рейтинг: 0 / 0
17.01.2007, 09:49
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34262976
akimovp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
akimovp
Гость
LeXa NalBat akimovp LeXa NalBatВ этих планах не используется индекс по dealerpayment(agent,paymentid). Попробуйте добиться такого плана.Я не знаю как заставить Postgresql его использовать в этом SQL.Удалите все индексы на таблицу dealerpayment кроме (agent,paymentid). Далее с помощью команд set enable_... to off/on.

Для HashJoin он все равно этот индекс не хочет использовать
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
 Sort  (cost= 48022 . 98 .. 48023 . 32  rows= 139  width= 8 ) (actual time= 16144 . 675 .. 16144 . 757  rows= 30  loops= 1 )
   Sort Key: date_part('year'::text, payment0_.accounted), date_part('month'::text, payment0_.accounted), date_part('day'::text, payment0_.accounted)
   ->  HashAggregate  (cost= 48015 . 60 .. 48018 . 03  rows= 139  width= 8 ) (actual time= 16144 . 420 .. 16144 . 521  rows= 30  loops= 1 )
         ->  Hash Join  (cost= 4714 . 72 .. 47343 . 68  rows= 89589  width= 8 ) (actual time= 9031 . 772 .. 15774 . 455  rows= 89988  loops= 1 )
               Hash Cond: ("outer".paymentid = "inner".id)
               ->  Seq Scan on dealerpayment comissions1_  (cost= 0 . 00 .. 34747 . 32  rows= 360790  width= 8 ) (actual time= 20 . 684 .. 12011 . 388  rows= 361975  loops= 1 )
                     Filter: ((agent)::text = 'pinpay'::text)
               ->  Hash  (cost= 4487 . 24 .. 4487 . 24  rows= 90992  width= 16 ) (actual time= 1677 . 368 .. 1677 . 368  rows= 90622  loops= 1 )
                     ->  Index Scan using payment_accounted on payment payment0_  (cost= 0 . 00 .. 4487 . 24  rows= 90992  width= 16 ) (actual time= 85 . 719 .. 1318 . 245  rows= 90622  loops= 1 )
                           Index Cond: ((accounted > '2006-12-01 00:00:00'::timestamp without time zone) AND (accounted < '2006-12-31 00:00:00'::timestamp without time zone))
 Total runtime:  16147 . 163  ms

Для MergeJoin использует - но результат хужее.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Group  (cost= 94103 . 88 .. 95671 . 69  rows= 89589  width= 8 ) (actual time= 22952 . 701 .. 23608 . 954  rows= 30  loops= 1 )
   ->  Sort  (cost= 94103 . 88 .. 94327 . 85  rows= 89589  width= 8 ) (actual time= 22952 . 690 .. 23283 . 284  rows= 89988  loops= 1 )
         Sort Key: date_part('year'::text, payment0_.datetime), date_part('month'::text, payment0_.datetime), date_part('day'::text, payment0_.datetime)
         ->  Merge Join  (cost= 82908 . 91 .. 86734 . 72  rows= 89589  width= 8 ) (actual time= 19321 . 965 .. 21955 . 207  rows= 89988  loops= 1 )
               Merge Cond: ("outer".id = "inner".paymentid)
               ->  Sort  (cost= 11975 . 00 .. 12202 . 48  rows= 90992  width= 16 ) (actual time= 1820 . 121 .. 2880 . 146  rows= 90622  loops= 1 )
                     Sort Key: payment0_.id
                     ->  Index Scan using payment_datetime on payment payment0_  (cost= 0 . 00 .. 4480 . 24  rows= 90992  width= 16 ) (actual time= 66 . 623 .. 1242 . 481  rows= 90622  loops= 1 )
                           Index Cond: ((datetime > '2006-12-01 00:00:00'::timestamp without time zone) AND (datetime < '2006-12-31 00:00:00'::timestamp without time zone))
               ->  Sort  (cost= 70933 . 91 .. 71835 . 89  rows= 360790  width= 8 ) (actual time= 16183 . 944 .. 17257 . 527  rows= 288189  loops= 1 )
                     Sort Key: comissions1_.paymentid
                     ->  Bitmap Heap Scan on dealerpayment comissions1_  (cost= 8498 . 45 .. 34293 . 33  rows= 360790  width= 8 ) (actual time= 3119 . 785 .. 13841 . 067  rows= 361975  loops= 1 )
                           Recheck Cond: ((agent)::text = 'pinpay'::text)
                           ->  Bitmap Index Scan on dealerpayment_agent_pid  (cost= 0 . 00 .. 8498 . 45  rows= 360790  width= 0 ) (actual time= 3089 . 529 .. 3089 . 529  rows= 361975  loops= 1 )
                                 Index Cond: ((agent)::text = 'pinpay'::text)
 Total runtime:  23629 . 100  ms
( 16  rows)
...
Рейтинг: 0 / 0
17.01.2007, 20:05
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34263922
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
akimovpДля HashJoin он все равно этот индекс не хочет использоватьHashjoin не нужен. akimovpДля MergeJoin использует - но результат хужее.Избавиьтесь в этом плане от bitmapscan-ов: set enable_bitmapscan to off.
...
Рейтинг: 0 / 0
18.01.2007, 11:02
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34266466
akimovp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
akimovp
Гость
LeXa NalBat akimovpДля HashJoin он все равно этот индекс не хочет использоватьHashjoin не нужен. akimovpДля MergeJoin использует - но результат хужее.Избавиьтесь в этом плане от bitmapscan-ов: set enable_bitmapscan to off.

если сделать set enable_bitmapscan = off - тогда он опять не использует этот индекс
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Group  (cost= 97405 . 83 .. 99059 . 00  rows= 93798  width= 8 ) (actual time= 16350 . 174 .. 16932 . 775  rows= 30  loops= 1 )
   ->  Sort  (cost= 97405 . 83 .. 97643 . 25  rows= 94968  width= 8 ) (actual time= 16350 . 165 .. 16643 . 398  rows= 89988  loops= 1 )
         Sort Key: date_part('year'::text, payment0_.datetime), date_part('month'::text, payment0_.datetime), date_part('day'::text, payment0_.datetime)
         ->  Merge Join  (cost= 85546 . 81 .. 89554 . 28  rows= 94968  width= 8 ) (actual time= 13675 . 739 .. 15395 . 169  rows= 89988  loops= 1 )
               Merge Cond: ("outer".id = "inner".paymentid)
               ->  Sort  (cost= 12147 . 55 .. 12382 . 04  rows= 93797  width= 16 ) (actual time= 1664 . 998 .. 1969 . 916  rows= 90622  loops= 1 )
                     Sort Key: payment0_.id
                     ->  Index Scan using payment_datetime on payment payment0_  (cost= 0 . 00 .. 4401 . 21  rows= 93797  width= 16 ) (actual time= 26 . 346 .. 1116 . 586  rows= 90622  loops= 1 )
                           Index Cond: ((datetime > '2006-12-01 00:00:00'::timestamp without time zone) AND (datetime < '2006-12-31 00:00:00'::timestamp without time zone))
               ->  Sort  (cost= 73399 . 26 .. 74338 . 12  rows= 375542  width= 8 ) (actual time= 10637 . 776 .. 11696 . 691  rows= 288189  loops= 1 )
                     Sort Key: comissions1_.paymentid
                     ->  Seq Scan on dealerpayment comissions1_  (cost= 0 . 00 .. 35137 . 16  rows= 375542  width= 8 ) (actual time= 17 . 236 .. 8192 . 709  rows= 366989  loops= 1 )
                           Filter: ((agent)::text = 'pinpay'::text)
 Total runtime:  16955 . 583  ms
( 14  rows)
...
Рейтинг: 0 / 0
18.01.2007, 21:01
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34266647
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
akimovpесли сделать set enable_bitmapscan = off - тогда он опять не использует этот индекс
Код: plaintext
1.
2.
3.
               ->  Sort  (cost= 73399 . 26 .. 74338 . 12  rows= 375542  width= 8 ) (actual time= 10637 . 776 .. 11696 . 691  rows= 288189  loops= 1 )
                     Sort Key: comissions1_.paymentid
                     ->  Seq Scan on dealerpayment comissions1_  (cost= 0 . 00 .. 35137 . 16  rows= 375542  width= 8 ) (actual time= 17 . 236 .. 8192 . 709  rows= 366989  loops= 1 )
                           Filter: ((agent)::text = 'pinpay'::text)
теперь сделайте set enable_seqscan to off
...
Рейтинг: 0 / 0
18.01.2007, 23:59
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34270057
akimovp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
akimovp
Гость
LeXa NalBat akimovpесли сделать set enable_bitmapscan = off - тогда он опять не использует этот индекс
Код: plaintext
1.
2.
3.
               ->  Sort  (cost= 73399 . 26 .. 74338 . 12  rows= 375542  width= 8 ) (actual time= 10637 . 776 .. 11696 . 691  rows= 288189  loops= 1 )
                     Sort Key: comissions1_.paymentid
                     ->  Seq Scan on dealerpayment comissions1_  (cost= 0 . 00 .. 35137 . 16  rows= 375542  width= 8 ) (actual time= 17 . 236 .. 8192 . 709  rows= 366989  loops= 1 )
                           Filter: ((agent)::text = 'pinpay'::text)
теперь сделайте set enable_seqscan to off

Сейчас помогло, и запрос значительно быстрее выполняется, раза в 2 визуально.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Group  (cost= 533741 . 77 .. 535431 . 80  rows= 96573  width= 8 ) 
(actual time= 7167 . 732 .. 7751 . 930  rows= 30  loops= 1 )
   ->  Sort  (cost= 533741 . 77 .. 533983 . 20  rows= 96573  width= 8 ) (actual time= 7167 . 721 .. 7462 . 039  rows= 89988  loops= 1 )
         Sort Key: date_part('year'::text, payment0_.datetime), date_part('month'::text, payment0_.datetime), date_part('day'::text, payment0_.datetime)
         ->  Merge Join  (cost= 15112 . 80 .. 525745 . 85  rows= 96573  width= 8 ) (actual time= 4200 . 893 .. 6183 . 306  rows= 89988  loops= 1 )
               Merge Cond: ("outer".id = "inner".paymentid)
               ->  Sort  (cost= 15112 . 80 .. 15400 . 83  rows= 115211  width= 16 ) (actual time= 2576 . 028 .. 2909 . 231  rows= 90622  loops= 1 )
                     Sort Key: payment0_.id
                     ->  Index Scan using payment_datetime on payment payment0_  (cost= 0 . 00 .. 5427 . 06  rows= 115211  width= 16 ) (actual time= 66 . 630 .. 1971 . 890  rows= 90622  loops= 1 ) 
                          Index Cond: ((datetime > '2006-12-01 00:00:00'::timestamp without time zone) AND (datetime < '2006-12-31 00:00:00'::timestamp without time zone))
               ->  Index Scan using dealerpayment_agent_pid on dealerpayment comissions1_  (cost= 0 . 00 .. 507412 . 29  rows= 381891  width= 8 ) (actual time= 39 . 311 .. 1466 . 032  rows= 288189  loops= 1 ) 
                    Index Cond: ((agent)::text = 'pinpay'::text) 
Total runtime:  7762 . 717  ms

Хотя мне от этого не легче потому что индекс ON dealerpayment USING btree (paymentid) мне тоже нужен для других запросов, где не используется поле agent, а при его создании уже другой план:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
 Group  (cost= 64829 . 96 .. 66411 . 24  rows= 90359  width= 8 ) (actual time= 16973 . 757 .. 17578 . 190  rows= 30  loops= 1 )
   ->  Sort  (cost= 64829 . 96 .. 65055 . 86  rows= 90359  width= 8 ) (actual time= 16973 . 746 .. 17278 . 757  rows= 89988  loops= 1 )
         Sort Key: date_part('year'::text, payment0_.datetime), date_part('month'::text, payment0_.datetime), date_part('day'::text, payment0_.datetime)
         ->  Merge Join  (cost= 15112 . 80 .. 57391 . 89  rows= 90359  width= 8 ) (actual time= 8102 . 011 .. 15940 . 129  rows= 89988  loops= 1 )
               Merge Cond: ("outer".paymentid = "inner".id)
               ->  Index Scan using dealerpayment_pid on dealerpayment comissions1_  (cost= 0 . 00 .. 40246 . 59  rows= 357318  width= 8 ) (actual time= 0 . 155 .. 10335 . 160  rows= 288189  loops= 1 )
                     Filter: ((agent)::text = 'pinpay'::text)
               ->  Sort  (cost= 15112 . 80 .. 15400 . 83  rows= 115211  width= 16 ) (actual time= 3330 . 963 .. 3678 . 274  rows= 90622  loops= 1 )
                     Sort Key: payment0_.id
                     ->  Index Scan using payment_datetime on payment payment0_  (cost= 0 . 00 .. 5427 . 06  rows= 115211  width= 16 ) (actual time= 221 . 608 .. 2741 . 044  rows= 90622  loops= 1 )
                           Index Cond: ((datetime > '2006-12-01 00:00:00'::timestamp without time zone) AND (datetime < '2006-12-31 00:00:00'::timestamp without time zone))
 Total runtime:  17589 . 098  ms
...
Рейтинг: 0 / 0
20.01.2007, 19:44
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34271307
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
akimovpХотя мне от этого не легче потому что индекс ON dealerpayment USING btree (paymentid) мне тоже нужен для других запросов, где не используется поле agent, а при его создании уже другой планПостгрес серьезно ошибается в оценке сложности различных способов сканирования dealerpayment. В идеале отношение предсказания cost_last_row к реальному времени actual_time_last_row должно быть одинаковым для ЛЮБЫХ запросов. Удивительно, что в вашем случае он ошибается очень сильно: 507412.29/1466.032=346 и 40246.59/10335.160=4. :-(

Мы боролись с подобной ошибкой (но она составляла не, как у вас, сто раз, а лишь несколько) изменением параметров оптимизатора . Изменение этих параметров влияет на планирование всех запросов, поэтому изменив их, можно "починить" один запрос, но "сломать" другой.

ИМХО, требуемые оптимальные значения этих параметров зависят например от того, в каком режиме работает ваша база. Например если она почти целиком лежит в оперативной памяти благодаря кэшированию ос, то надо выбрать одни значения, наоборот если большинство запросов интенсивно дергают данные с hdd, то - совсем другие.

У нас установлены значения effective_cache_size = 8192, random_page_cost = 2. Взгляните на темы, в которых упоминается random_page_cost .
...
Рейтинг: 0 / 0
22.01.2007, 10:29
| Ответить | Цитировать | Написать  
опять оптимизация запроса
    #34273468
akimovp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
akimovp
Гость
LeXa NalBat akimovpХотя мне от этого не легче потому что индекс ON dealerpayment USING btree (paymentid) мне тоже нужен для других запросов, где не используется поле agent, а при его создании уже другой планПостгрес серьезно ошибается в оценке сложности различных способов сканирования dealerpayment. В идеале отношение предсказания cost_last_row к реальному времени actual_time_last_row должно быть одинаковым для ЛЮБЫХ запросов. Удивительно, что в вашем случае он ошибается очень сильно: 507412.29/1466.032=346 и 40246.59/10335.160=4. :-(

Мы боролись с подобной ошибкой (но она составляла не, как у вас, сто раз, а лишь несколько) изменением параметров оптимизатора . Изменение этих параметров влияет на планирование всех запросов, поэтому изменив их, можно "починить" один запрос, но "сломать" другой.

ИМХО, требуемые оптимальные значения этих параметров зависят например от того, в каком режиме работает ваша база. Например если она почти целиком лежит в оперативной памяти благодаря кэшированию ос, то надо выбрать одни значения, наоборот если большинство запросов интенсивно дергают данные с hdd, то - совсем другие.

У нас установлены значения effective_cache_size = 8192, random_page_cost = 2. Взгляните на темы, в которых упоминается random_page_cost .

Спасибо за помощь, но все это напоминает какие-то танцы c бубном, можно потратить на это время изменить что-то в одном месте , настроить более менее один запрос, а потом окажется что в другом месте стало плохо.
Сейчас я добился более менее приемлемого результата путем CLUSTER payment по id и dealerpayment по paymentid и еще создал индексы для каждой части даты extract. Ну и естественно каждой ночью VACUUM, CLUSTER, REINDEX.
Жду большого увеличения данных и поэтому сейчас буду тратить время не на непредсказуемый tuning postgres а на миграцию и тестирование на других базах. Может кто посоветует стоит ли пробовать InnoDB или еще что-то, или сразу на oracle все пытаться перенести. С последним меня пугает чуство чего-то глобального и сложного и малое знакомство в области администрирования Oracle.
...
Рейтинг: 0 / 0
22.01.2007, 20:13
| Ответить | Цитировать | Написать  
18 сообщений из 43, страница 2 из 2
  2  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / опять оптимизация запроса
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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