powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / PGSQL. Разочарование близко 2.
18 сообщений из 43, страница 2 из 2
PGSQL. Разочарование близко 2.
    #34268228
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShweikЧестно говоря сразу хотелось подобным образовы выразиться и закрыть эти слезливые топики....Этот топик конструктивный, с конкретным вопросом, потребовавшим разбирательства, закрыть его было бы неправильно.
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34268430
Shweik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IMHO если и дальше будут сравнивать планировщики
SQL2005 и PG - этому топику здесь не место.
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34268492
zsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zsm
Гость
ShweikIMHO если и дальше будут сравнивать планировщики
SQL2005 и PG - этому топику здесь не место.

Не могу с этим согласится.
Полезность данного топика я вижу прежде всего в том, что удалось выявить и обнародовать существенные недостатки планировщика PG.
Теперь, те кто в курсе, будут учитывать это в своей работе.
А обнаружить их удалось, прежде всего, благодаря сравнительному анализу с другими, более мощными, планировщиками (конкурентами язык не поворачивается назвать ;-)).
Да, от увиденного, хочется немного впалкнуть, но вместо этого, прдлагаю начать "массовую атаку" на pgsql-hackers-owner@postgresql.org, ибо, все остальное в PG радует, по крайней мере пока ;)
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34268574
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShweikIMHO если и дальше будут сравнивать планировщики
SQL2005 и PG - этому топику здесь не место.Тогда не закрыть, а перенести в Сравнение СУБД?
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34268623
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeXa NalBat ShweikIMHO если и дальше будут сравнивать планировщики
SQL2005 и PG - этому топику здесь не место.Тогда не закрыть, а перенести в Сравнение СУБД?не-а.
топег интересен именно для постгресистов - на предмет представлять себе, как строить структуры и писать запросы, шобы именно постгрессовский оптимайзер....

а "сравнение" - общая свалка - для пофлудить.
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34269592
СергейК
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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.
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34319880
Yuriy Yurchenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дабы не плодить еще одну тему, пишу сюда.
Есть простенькая табличка (приводить смысла нет, конфиг по умолчанию), всего 1млн записей, ключи и индексы присутствуют, но... запрос
Код: plaintext
select count(id) from blablabla
отрабатывается в течение от 35 до 46 секунд!!! В то же время такой запрос на MS SQL отрабатывается в разы, а то и десятки раз быстрее!

Подскажите, неужели у PostgressSQL все так запущено или надо что-то подкрутить?
Комп - PIII 866, 512 RAM.
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34319994
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yuriy YurchenkoДабы не плодить еще одну тему, пишу сюда.
Есть простенькая табличка (приводить смысла нет, конфиг по умолчанию), всего 1млн записей, ключи и индексы присутствуют, но... запрос
Код: plaintext
select count(id) from blablabla
отрабатывается в течение от 35 до 46 секунд!!! В то же время такой запрос на MS SQL отрабатывается в разы, а то и десятки раз быстрее!

Подскажите, неужели у PostgressSQL все так запущено или надо что-то подкрутить?
Комп - PIII 866, 512 RAM.
Да, в постгресе очень запущеный count() (поиск по форуму рулит).
В кратце:
Происходит чтение с винта всей таблицы, точнее физический просмотр (seqscan). Так что если таблица шириной в 4Кб, то будет прочитано с винта все 1млн*4Кб=4Гб данных. Время прочтения легко подсчитать самому. Опять же есть счастливые операции VACUUM ANALYZE и VACUUM FULL ANALYZE для частообновляемых таблиц. Опять же есть повышение версии до более новой. Опять же веники есть более шустрые.
Да, в МССКЛ (особенно как блокировщику) все будет в сотни, да нет, в тысячи десятков раз быстрее за счет использования индекса. Или, например, не совсем честная реализация count() в FireBird'е - будет тоже быстрее.
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34320092
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yuriy Yurchenkoзапрос select count(id) from blablabla отрабатывается в течение от 35 до 46 секунд!!!count по всей таблице долго обсуждали тут
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34320145
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrey DaeronИли, например, не совсем честная реализация count() в FireBird'е - будет тоже быстрее.
и в чем же ее нечестность? Реализация абсолютно аналогичная PGSQL'ной, с теми же недостатками.
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34320190
Shweik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Однозначно могу сказать одно таблицы с 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.
Welcome to psql  8 . 1 . 3 , the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

atslog=#  select count(duration) from c2  where timeofcall  >='2006-11-1' and timeofcall<'2006-11-30';
 count  
--------
  437228 
( 1  row)

atslog=#  select count(duration) from c1  where timeofcall  >='2006-11-1' and timeofcall<'2006-11-30';
 count  
--------
  437228 
( 1  row)

atslog=#  select count(duration) from c1;                                                             
  count  
---------
  2985488 
( 1  row)

atslog=#  select count(duration) from c2;
  count  
---------
  2985488 
( 1  row)

atslog=# 

--------------------------------------а вот лог------------------
tail -f $PGDATA/serverlog 
LOG:  checkpoint record is at  0 /74D34418
LOG:  redo record is at  0 /74D34418; undo record is at  0 / 0 ; shutdown TRUE
LOG:  next transaction ID:  1544818 ; next OID:  273907 
LOG:  next MultiXactId:  1 ; next MultiXactOffset:  0 
LOG:  database system is ready
LOG:  transaction ID wrap limit is  1075277484 , limited by database "tst1"
LOG:  statement: select count(duration) from c2  where timeofcall  >='2006-11-1' and timeofcall<'2006-11-30';
LOG:  duration:  5499 . 181  ms
LOG:  statement: select count(duration) from c1  where timeofcall  >='2006-11-1' and timeofcall<'2006-11-30';
LOG:  duration:  3347 . 500  ms
LOG:  statement: select count(duration) from c1;
LOG:  duration:  6358 . 656  ms
LOG:  statement: select count(duration) from c2;
LOG:  duration:  1854 . 537  ms
-----------------------------------чуть  не забыл структуру таблиц-----------------------
atslog=# \d c2
                  Table "public.c2"
   Column   |            Type             | Modifiers 
------------+-----------------------------+-----------
 timeofcall | timestamp without time zone | 
 forwarded  | character( 3 )                | 
 internally | smallint                    | 
 co         | smallint                    | 
 way        | character( 3 )                | 
 number     | numeric( 100 , 0 )              | 
 duration   | integer                     | 
 cost       | numeric( 100 , 3 )              | 
--------------------------------------------------------------------------------------------
atslog=# \d c1
                  Table "public.c1"
   Column   |            Type             | Modifiers 
------------+-----------------------------+-----------
 timeofcall | timestamp without time zone | 
 forwarded  | character( 3 )                | 
 internally | smallint                    | 
 co         | smallint                    | 
 way        | character( 3 )                | 
 number     | numeric( 100 , 0 )              | 
 duration   | integer                     | 
 cost       | numeric( 100 , 3 )              | 
Rules:
    c1_yy06mm07_ins AS
    ON INSERT TO c1
   WHERE new.timeofcall >= '2006-07-01'::date AND new.timeofcall < '2006-08-01'::date DO INSTEAD  INS
_yy06mm07 (timeofcall, forwarded, internally, co, way, number, duration, cost) 
  VALUES (new.timeofcall, new.forwarded, new.internally, new.co, new.way, new.number, new.duration, n
    c1_yy06mm08_ins AS
    ON INSERT TO c1
   WHERE new.timeofcall >= '2006-08-01'::date AND new.timeofcall < '2006-09-01'::date DO INSTEAD  INS
_yy06mm08 (timeofcall, forwarded, internally, co, way, number, duration, cost) 
  VALUES (new.timeofcall, new.forwarded, new.internally, new.co, new.way, new.number, new.duration, n
    c1_yy06mm09_ins AS
    ON INSERT TO c1
   WHERE new.timeofcall >= '2006-09-01'::date AND new.timeofcall < '2006-10-01'::date DO INSTEAD  INS
_yy06mm09 (timeofcall, forwarded, internally, co, way, number, duration, cost) 
  VALUES (new.timeofcall, new.forwarded, new.internally, new.co, new.way, new.number, new.duration, n
    c1_yy06mm10_ins AS
......
Если хотит узнать больше читайте далее
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34320309
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr Andrey DaeronИли, например, не совсем честная реализация count() в FireBird'е - будет тоже быстрее.
и в чем же ее нечестность? Реализация абсолютно аналогичная PGSQL'ной, с теми же недостатками.
Где-то на этом форме читал про ее неатомарность, за счет использования индексов которые живут ессно вне транзакций. Т.е. есть транзация которая вставляет по 1000 записей и их комитит, и есть другая которая говорит count(). Есть ситуации, при которых в count() будет кол-во записей не кратное 1000. ИМХО это было про 1.5х версию. Опять же с подробностями - не сюда, а к фаербердистам.
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34320697
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrey DaeronГде-то на этом форме читал про ее неатомарность, за счет использования индексов которые живут ессно вне транзакций. Т.е. есть транзация которая вставляет по 1000 записей и их комитит, и есть другая которая говорит count(). Есть ситуации, при которых в count() будет кол-во записей не кратное 1000
неатомарность может иметь место, но эта тема не связана с данной :-) Реализация индексов в FB очень схожа с PG'шной: ID тр-ции не включается в ключ, поэтому только индексным покрытием никакой запрос не решается - надо читать саму запись. И count() работает там абсолютно идентично.
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34320787
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
create table test ( id integer );
insert into test select generate_series(  1 ,  10000000  );
create index test_id on test ( id );
analyze test;

explain analyze select count(*) from test;
-- Aggregate
--   ->  Seq Scan on test
-- Total runtime: 7995.084 ms

explain analyze select count(*) from test where id between  1  and  10000000 ;
-- Aggregate
--   ->  Seq Scan on test
--         Filter
-- Total runtime: 10745.015 ms

set enable_seqscan to off;
explain analyze select count(*) from test where id between  1  and  10000000 ;
-- Aggregate
--   ->  Index Scan using test_id on test
--         Index Cond
-- Total runtime: 11571.531 ms

set enable_indexscan to off;
explain analyze select count(*) from test where id between  1  and  10000000 ;
-- Aggregate
--   ->  Bitmap Heap Scan on test
--         Recheck Cond
--         ->  Bitmap Index Scan on test_id
--               Index Cond
-- Total runtime:  11744 . 532  ms
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34324562
Shweik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeXa NalBat2 Shweik.

По результатам вашего примера касательно простой таблицы c2 можно сделать вывод, что безусловное сканирование 3 миллионов строк работает в три раза быстрее, чем сканирование с условием 440 тысяч строк, то есть имеет место примерно двадцатикратная разница в скорости?

По какому плану выполняется запрос по таблице c2 с условием where?

Сорри - я хотел проверить мое предположение о том что с эффективностью разбития таблиц на слайсы твориться что-то непонятное. (и забыл создать индекс для с2.timeofcall !!! 8-( )
В приложении планы запросов из предыдущего поста по таблицам с1 (разбитая на слайсы ) и с2 (обычная здоровая). Возможно я где-то накосячил, но пока что тенденция такая - запрос с условием
или без оного на паритционированной таблице НЕБЫСТРЕЕ монолитной. А почему...? 8-0
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34326264
Funny_Falcon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Похоже партицирование не сработало. Судя по документации, если на таблицах есть соответствующие CHECK -и, то должны были проверяться только подходящие таблицы. А у тебя все проверяются.
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34327334
СергейК
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Funny_FalconПохоже партицирование не сработало. Судя по документации, если на таблицах есть соответствующие CHECK -и, то должны были проверяться только подходящие таблицы. А у тебя все проверяются.

Mojet byt' tam problema analogichnaia
...
Рейтинг: 0 / 0
PGSQL. Разочарование близко 2.
    #34327342
СергейК
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Sorry, ne razobralsia kak tut linki stavit:
Модератор: Ничего страшного, поправим.
план запроса к партиционной таблице
...
Рейтинг: 0 / 0
18 сообщений из 43, страница 2 из 2
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / PGSQL. Разочарование близко 2.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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