Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
ShweikЧестно говоря сразу хотелось подобным образовы выразиться и закрыть эти слезливые топики....Этот топик конструктивный, с конкретным вопросом, потребовавшим разбирательства, закрыть его было бы неправильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2007, 14:16 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
IMHO если и дальше будут сравнивать планировщики SQL2005 и PG - этому топику здесь не место. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2007, 14:53 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
ShweikIMHO если и дальше будут сравнивать планировщики SQL2005 и PG - этому топику здесь не место. Не могу с этим согласится. Полезность данного топика я вижу прежде всего в том, что удалось выявить и обнародовать существенные недостатки планировщика PG. Теперь, те кто в курсе, будут учитывать это в своей работе. А обнаружить их удалось, прежде всего, благодаря сравнительному анализу с другими, более мощными, планировщиками (конкурентами язык не поворачивается назвать ;-)). Да, от увиденного, хочется немного впалкнуть, но вместо этого, прдлагаю начать "массовую атаку" на pgsql-hackers-owner@postgresql.org, ибо, все остальное в PG радует, по крайней мере пока ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2007, 15:09 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
ShweikIMHO если и дальше будут сравнивать планировщики SQL2005 и PG - этому топику здесь не место.Тогда не закрыть, а перенести в Сравнение СУБД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2007, 15:26 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat ShweikIMHO если и дальше будут сравнивать планировщики SQL2005 и PG - этому топику здесь не место.Тогда не закрыть, а перенести в Сравнение СУБД?не-а. топег интересен именно для постгресистов - на предмет представлять себе, как строить структуры и писать запросы, шобы именно постгрессовский оптимайзер.... а "сравнение" - общая свалка - для пофлудить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2007, 15:43 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat zsmЯ слабо представляю, как реализована сортировка, но смею предположить, что по крайней мере все ключи придется сначала брать из таблиц и где-то их размещать.Не знаю, как в постгресе реализована сортировка. Iz ishodnikov: Small amounts are sorted in-memory using qsort(). Large amounts are sorted using temporary files and a standard external sort algorithm. See Knuth, volume 3, for more than you want to know about the external sorting algorithm. We divide the input into sorted runs using replacement selection, in the form of a priority tree implemented as a heap (essentially his Algorithm 5.2.3H), then merge the runs using polyphase merge, Knuth's Algorithm 5.4.2D. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2007, 03:03 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
Дабы не плодить еще одну тему, пишу сюда. Есть простенькая табличка (приводить смысла нет, конфиг по умолчанию), всего 1млн записей, ключи и индексы присутствуют, но... запрос Код: plaintext Подскажите, неужели у PostgressSQL все так запущено или надо что-то подкрутить? Комп - PIII 866, 512 RAM. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2007, 16:02 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
Yuriy YurchenkoДабы не плодить еще одну тему, пишу сюда. Есть простенькая табличка (приводить смысла нет, конфиг по умолчанию), всего 1млн записей, ключи и индексы присутствуют, но... запрос Код: plaintext Подскажите, неужели у PostgressSQL все так запущено или надо что-то подкрутить? Комп - PIII 866, 512 RAM. Да, в постгресе очень запущеный count() (поиск по форуму рулит). В кратце: Происходит чтение с винта всей таблицы, точнее физический просмотр (seqscan). Так что если таблица шириной в 4Кб, то будет прочитано с винта все 1млн*4Кб=4Гб данных. Время прочтения легко подсчитать самому. Опять же есть счастливые операции VACUUM ANALYZE и VACUUM FULL ANALYZE для частообновляемых таблиц. Опять же есть повышение версии до более новой. Опять же веники есть более шустрые. Да, в МССКЛ (особенно как блокировщику) все будет в сотни, да нет, в тысячи десятков раз быстрее за счет использования индекса. Или, например, не совсем честная реализация count() в FireBird'е - будет тоже быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2007, 16:29 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
Yuriy Yurchenkoзапрос select count(id) from blablabla отрабатывается в течение от 35 до 46 секунд!!!count по всей таблице долго обсуждали тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2007, 17:02 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
Andrey DaeronИли, например, не совсем честная реализация count() в FireBird'е - будет тоже быстрее. и в чем же ее нечестность? Реализация абсолютно аналогичная PGSQL'ной, с теми же недостатками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2007, 17:20 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
Однозначно могу сказать одно таблицы с count(*) >1000 000 вполне имеет смысл делить на партиции. Вот банальный пример: Код: 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. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2007, 17:34 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
dimitr Andrey DaeronИли, например, не совсем честная реализация count() в FireBird'е - будет тоже быстрее. и в чем же ее нечестность? Реализация абсолютно аналогичная PGSQL'ной, с теми же недостатками. Где-то на этом форме читал про ее неатомарность, за счет использования индексов которые живут ессно вне транзакций. Т.е. есть транзация которая вставляет по 1000 записей и их комитит, и есть другая которая говорит count(). Есть ситуации, при которых в count() будет кол-во записей не кратное 1000. ИМХО это было про 1.5х версию. Опять же с подробностями - не сюда, а к фаербердистам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2007, 18:16 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
Andrey DaeronГде-то на этом форме читал про ее неатомарность, за счет использования индексов которые живут ессно вне транзакций. Т.е. есть транзация которая вставляет по 1000 записей и их комитит, и есть другая которая говорит count(). Есть ситуации, при которых в count() будет кол-во записей не кратное 1000 неатомарность может иметь место, но эта тема не связана с данной :-) Реализация индексов в FB очень схожа с PG'шной: ID тр-ции не включается в ключ, поэтому только индексным покрытием никакой запрос не решается - надо читать саму запись. И count() работает там абсолютно идентично. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2007, 22:36 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
2 Shweik. По результатам вашего примера касательно простой таблицы c2 можно сделать вывод, что безусловное сканирование 3 миллионов строк работает в три раза быстрее, чем сканирование с условием 440 тысяч строк, то есть имеет место примерно двадцатикратная разница в скорости? По какому плану выполняется запрос по таблице c2 с условием where? Нижеследующий пример показывает, что запрос с условием примерно в полтора раза медленнее безусловного запроса, а не в 20 раз. :-О Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2007, 00:05 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat2 Shweik. По результатам вашего примера касательно простой таблицы c2 можно сделать вывод, что безусловное сканирование 3 миллионов строк работает в три раза быстрее, чем сканирование с условием 440 тысяч строк, то есть имеет место примерно двадцатикратная разница в скорости? По какому плану выполняется запрос по таблице c2 с условием where? Сорри - я хотел проверить мое предположение о том что с эффективностью разбития таблиц на слайсы твориться что-то непонятное. (и забыл создать индекс для с2.timeofcall !!! 8-( ) В приложении планы запросов из предыдущего поста по таблицам с1 (разбитая на слайсы ) и с2 (обычная здоровая). Возможно я где-то накосячил, но пока что тенденция такая - запрос с условием или без оного на паритционированной таблице НЕБЫСТРЕЕ монолитной. А почему...? 8-0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2007, 16:42 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
Похоже партицирование не сработало. Судя по документации, если на таблицах есть соответствующие CHECK -и, то должны были проверяться только подходящие таблицы. А у тебя все проверяются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2007, 11:02 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
Funny_FalconПохоже партицирование не сработало. Судя по документации, если на таблицах есть соответствующие CHECK -и, то должны были проверяться только подходящие таблицы. А у тебя все проверяются. Mojet byt' tam problema analogichnaia ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2007, 14:54 |
|
||
|
PGSQL. Разочарование близко 2.
|
|||
|---|---|---|---|
|
#18+
Sorry, ne razobralsia kak tut linki stavit: Модератор: Ничего страшного, поправим. план запроса к партиционной таблице ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2007, 14:55 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=34326264&tid=2005707]: |
0ms |
get settings: |
9ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
52ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 348ms |

| 0 / 0 |
