|
|
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Вопрос, наверное, больше к специалистам по PostgreSQL. Обьясните, пожалуйста, почему нижеследующий запрос выполняется на Oracle 10g 40 сек, а на PostgreSQL 8.3 - 1:30 сек. Железо одинаковое. В чём может быть проблема на PG? Таблица PG: CREATE TABLE "public"."space_acc" ( "dat" TIMESTAMP WITHOUT TIME ZONE NOT NULL, "gbytes" NUMERIC NOT NULL, CONSTRAINT "space_acc_pkey" PRIMARY KEY("dat") ) WITHOUT OIDS; Идентичная таблица Oracle: create table ( DAT DATE not null, GBYTES NUMBER not null ); alter table add primary key (DAT) using index; Заполнение таблицы Oracle: Код: plaintext 1. 2. 3. 4. ЗАПРОС для замера времени (у меня на PG = 1:30 сек): Код: plaintext 1. 2. 3. 4. 5. План Oracle: Код: plaintext 1. 2. 3. 4. 5. 6. План PG: Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2009, 22:11 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
Файл данных для PG. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2009, 22:18 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
Файл данных ORA. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2009, 22:18 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
Оператор "<" в Постгресе не может использоваться для MERGE JOIN. 50 миллионов итераций в NESTED LOOP естественно тормозят. Скорее всего поможет только переписывание запроса, в данном примере заменить группировку на подзапрос. В Оракле это тоже значительное ускорение даст. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2009, 05:38 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
можно изменить запрос, тогда он будет выполняться на постгресе гораздо быстрее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2009, 11:28 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
web_foxОбьясните, пожалуйста, почему нижеследующий запрос выполняется на Oracle 10g 40 сек, а на PostgreSQL 8.3 - 1:30 сек. Железо одинаковое. В чём может быть проблема на PG? Основная проблема совершенно точно не в PG. Посмотрите, пожалуйста, внимательно: Код: plaintext 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. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. Полагаю, когда лёгким движением руки запрос может быть ускорен с семидесяти секунд до пятидесяти тысячных долей секунды - рассуждать о сравнении серверов немного неуместно. Вообще, фраза "сорок секунд на десяти тысячах записей" должна звучать похоронным колоколом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2009, 12:27 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
softwarer, c PostgreSQL прецеденты были))))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2009, 13:03 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
softwarer, план для вашего варианта в Постгре запрос (выполнился за 47 милисекунд) Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2009, 13:13 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
web_fox, ваш запрос выполнился за 46 секунд Код: plaintext 1. 2. 3. 4. 5. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2009, 13:14 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
Спасибо за ответы. В данном случае интересует больше не сама возможность ускорить данный запрос, а конкретная причина его медленного выполнения на PG. Как я понял, это из-за авторОператор "<" в Постгресе не может использоваться для MERGE JOIN Где можно прочитать остальные особенности работы PG именно при выполнении/построении планов запросов? Если в сравнении с Oracle, то вообще идеально. В PG новичёк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2009, 16:37 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
web_fox, а какое у вас железо? Меня просто интересует почему мой результат 47 секунд, а не 70? Версия PostgreSQL 8.4. Это они так его оптимизировали, или это разница в железе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2009, 18:30 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕН, я всё запускал на домашнем компе: двухядерный AMD 4000+, WinXPSP3. PG 8.3.7 = 90 сек PG 8.4 = 90 сек планы одинаковые. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2009, 21:09 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕН, обе версии PG во время выполнения использовали одно ядро, т.е. 50%. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2009, 21:10 |
|
||
|
PostgreSQL/Oracle на конкретном запросе. Почему так?
|
|||
|---|---|---|---|
|
#18+
web_fox, рискну предположить, что запросы, на которых планировщик особенно "проседает" есть в любой СУБД. Это данность, зависящая от реализации каждой конкретной СУБД. В постгрессовские исходники не заглядывал. А может стоит задачка написать особенно тормозной проект?))) Их есть у меня)) Надо в опциях задать, например, запрет на сканирование индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2009, 22:13 |
|
||
|
|

start [/forum/topic.php?fid=35&fpage=21&tid=1552960]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
84ms |
get tp. blocked users: |
2ms |
| others: | 276ms |
| total: | 446ms |

| 0 / 0 |
