ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / PGSQL. Разочарование близко 2.
43 сообщений из 43, показаны все 2 страниц
  все  
PGSQL. Разочарование близко 2.
    #34260112
zsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zsm
Гость
Вот один из простеньких примеров, который призван продемонстрировать некоторую "недалекость" планировщика.

Создаем 2 таблицы и наполняем их:
Код: 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.
CREATE TABLE t1 (
  utc timestamp,
  uid int,
  PRIMARY KEY( utc )
);

CREATE TABLE t2 (
  utc timestamp,
  uid int,
  PRIMARY KEY( utc )
);

CREATE OR REPLACE FUNCTION Fill_t12 ()
RETURNS void
LANGUAGE plpgsql AS $$
DECLARE
  dt timestamp = '2007-01-01';
BEGIN
FOR i IN  1 .. 100000  LOOP
	INSERT INTO t1 VALUES( dt, i );
	INSERT INTO t2 VALUES( dt, -i );
	dt := dt + '00:00:01.000';
END LOOP;	
END
$$;


А затем смотрим что нам скажет EXPLAIN на следующий запрос:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SELECT * FROM
(
    SELECT * FROM t1
        UNION ALL
    SELECT * FROM t2
) s WHERE utc > '2007-01-01 00:00' and utc <= '2007-01-01 05:00' 
ORDER BY utc;

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Sort  (cost=5207.69..5304.53 rows=38736 width=12)
  Sort Key: s.utc
  ->  Result  (cost=0.00..1461.24 rows=38736 width=12)
        ->  Append  (cost=0.00..1461.24 rows=38736 width=12)
              ->  Index Scan using t1_pkey on t1  (cost=0.00..713.48 rows=18861 width=12)
                    Index Cond: ((utc > '2007-01-01 00:00:00'::timestamp without time zone) AND (utc <= '2007-01-01 05:00:00'::timestamp without time zone))
              ->  Index Scan using t2_pkey on t2  (cost=0.00..747.76 rows=19875 width=12)
                    Index Cond: ((utc > '2007-01-01 00:00:00'::timestamp without time zone) AND (utc <= '2007-01-01 05:00:00'::timestamp without time zone))


Так вот, непонятно, почему нельзя обойтись без сортировки в конце?
Или я чего-то не понимаю?
...
Рейтинг: 0 / 0
16.01.2007, 22:19
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34260194
СергейК
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
СергейК
Гость
zsmТак вот, непонятно, почему нельзя обойтись без сортировки в конце?
Или я чего-то не понимаю?

Potomu chto chtenie iz tablits t1, t2 budet idti ne sinhronno, a posledovatelno... Poetomu "Append node" snachala vydast otsortirovannye el-ty iz t1, a potom dobaviatsia otsortirovannye el-ty iz t2. Poetomu ob'edinenny spisok nado sortirovat'...

Vopros, mojno li eto schitat' serionym nedostatkom planera ? Vriad li.
Ne znau konechno, no dumayu chto i drugie DMBS vybiraut takoi-je plan...
...
Рейтинг: 0 / 0
17.01.2007, 00:07
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34260727
st_serg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
st_serg
Участник
в oracle9i план аналогичный
...
Рейтинг: 0 / 0
17.01.2007, 10:27
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34260801
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
zsmВот один из простеньких примеров, который призван продемонстрировать некоторую "недалекость" планировщика.

Кста, а в SQL2005 какой план?
...
Рейтинг: 0 / 0
17.01.2007, 10:47
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34262190
zsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zsm
Гость
авторКста, а в SQL2005 какой план?

Для SQL2005 делаем следующее:

Код: 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 t1 (
  utc datetime,
  uid int,
  PRIMARY KEY( utc )
);

CREATE TABLE t2 (
  utc datetime,
  uid int,
  PRIMARY KEY( utc )
);

GO
CREATE PROCEDURE Fill_t12
AS
    DECLARE @dt datetime;
    DECLARE @i int;

	SET @i =  0 ;
	SET @dt = '2007-01-01';
	
	BEGIN TRAN;
	WHILE ( @i <  100000  ) BEGIN
		INSERT INTO t1 VALUES( @dt, @i );
		INSERT INTO t2 VALUES( @dt, -@i );
		SET @i = @i +  1 ;
		SET @dt = @dt + '00:00:01.000';
	END;
	COMMIT TRAN;
	
EXEC Fill_t12;

Запрос тот же:

Код: plaintext
1.
2.
3.
4.
5.
6.
SELECT * FROM
(
    SELECT * FROM t1
        UNION ALL
    SELECT * FROM t2
) s WHERE utc > '2007-01-01 00:00' and utc <= '2007-01-01 05:00' 
ORDER BY utc;

Как получить план исполнения в текстовом, читабельном виде, так понять и не удалось, поэтому см. screenshot во вложении.
Можно видеть, что здесь все очень просто и изящно.
Кстати, в SQL2000 план точно такой же.

авторVopros, mojno li eto schitat' serionym nedostatkom planera ? Vriad li.
Ne znau konechno, no dumayu chto i drugie DMBS vybiraut takoi-je plan...
Не могу с этим согласится.
Если число аналогичных таблиц в UNION ALL достаточно велико (в моем случае именно так), а также досточно много записей в одном SELECT, то тормоза будут существенными.

Хочу заметить, что сравнительный анализ PG и SQL2005 я провожу не ради интереса, а по необходимости: проектируемое серверное приложение должно уметь работать с обоими типами DBMS .
Помимо анализа SELECT-запросов, был проведен основательный анализ (с последующей оптимизацией) скорости работы bulk copy, как самого быстрого способа вставки новых записей.

В моих тестах, PG проигрывает в производительности по всем статьям примерно в 2 раза, как это ни печально ;(
...
Рейтинг: 0 / 0
17.01.2007, 16:01
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34262320
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
zsm
Как получить план исполнения в текстовом, читабельном виде, так понять и не удалось, поэтому см. screenshot во вложении.
Можно видеть, что здесь все очень просто и изящно.
Кстати, в SQL2000 план точно такой же.

Ну в принципе да, только не понятно (по плану) будет ли произведена сортировка результата вообще. И если да, то когда - Clust. index scan - это никак не сортировка. Merj Join - тоже.
В общем - ощущение, что план от МС не полон. И для PG лучше сразу приводить не только план, но и результат его выполнения в реальной жизни т.е. EXPLAINE ANALYZE.

zsm
Если число аналогичных таблиц в UNION ALL достаточно велико (в моем случае именно так), а также досточно много записей в одном SELECT, то тормоза будут существенными.

Сортировку на каком-то этапе даже SQL2005 прийдется делать. Так что вопрос скорее нужно проверять на практике.

zsm
Помимо анализа SELECT-запросов, был проведен основательный анализ (с последующей оптимизацией) скорости работы bulk copy, как самого быстрого способа вставки новых записей.

В моих тестах, PG проигрывает в производительности по всем статьям примерно в 2 раза, как это ни печально ;(
А здеся можно и fsynk отключить для PG, и на линух перейти (авось поможет ). Хотя спору нет, скорость вставки у МС, особенно, по идее, как блокировщика - на высоте.

А на счет в 2-раза на селектах - не верю. Я думаю, если это таки правда - нафига вообще этот PG кому сдался - есть лучшая RDBMS всех времен и народофф от МС .
...
Рейтинг: 0 / 0
17.01.2007, 16:37
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34262458
Funny_Falcon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Funny_Falcon
Участник
авторНу в принципе да, только не понятно (по плану) будет ли произведена сортировка результата вообще. И если да, то когда - Clust. index scan - это никак не сортировка. Merj Join - тоже.

Merge Join - это упорядоченное слияние упорядоченных наборов. Т.е. результирующий набор будет отсортирован.
...
Рейтинг: 0 / 0
17.01.2007, 17:10
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34262475
zsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zsm
Гость
Andrey Daeron
Ну в принципе да, только не понятно (по плану) будет ли произведена сортировка результата вообще. И если да, то когда - Clust. index scan - это никак не сортировка. Merj Join - тоже.
В общем - ощущение, что план от МС не полон. И для PG лучше сразу приводить не только план, но и результат его выполнения в реальной жизни т.е. EXPLAINE ANALYZE.

Сортировка произведена не будет, поэтому в плане ее и нет.
В том то вся фишка, что обход по индексам + грамотный merge, и в итоге получаем правильно упорядоченную выборку.

Andrey Daeron
Сортировку на каком-то этапе даже SQL2005 прийдется делать. Так что вопрос скорее нужно проверять на практике.

Так собтсвенно из практики все эти утверждения.

Andrey Daeron
А на счет в 2-раза на селектах - не верю. Я думаю, если это таки правда - нафига вообще этот PG кому сдался - есть лучшая RDBMS всех времен и народофф от МС .
Про тривиальные запросы, а точнее, про запросы для которых планировщик выдает хороший план, я не говорю - тут тема отдельного исследования.
А вот то, что основное падение производительности следствие недостаточной интеллектуальности планировщика, увы, но факт. И не спасет тут никакой кэш, управление процесами и т.п.
А проявляется эта интелектальность на более менее сложных запросах.
Алгоритм обработки данных - вот первое, что нужно оптимизировать в любой программе, а уже потом поднимать частоту процессора, заниматься переписыванием на asm и т.д.
Что-то мне подсказывает, что планировщик, это и есть самая сложная часть в СУБД.

Andrey Daeron
А здеся можно и fsynk отключить для PG, и на линух перейти (авось поможет ). Хотя спору нет, скорость вставки у МС, особенно, по идее, как блокировщика - на высоте.

Перейти на *nix - думаю это не панацея.
Да и, честно говоря, нет такой возможности.

Наверное, я бы и не стал связываться с PG, но слишком недешевое удовольствие - SQL2005.
Шибко на себестоимость продукта влияет ;-)
А из фриварных, кроме PG, другой достойной альтернативы просто не наблюдается.
Так что приходится как-то выкручиваться...
...
Рейтинг: 0 / 0
17.01.2007, 17:15
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34262619
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
Mergejoin в этом примере работает намного медленнее, чем sort. :-O Объяснить не могу, может быть выделение памяти...

Код: 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.
create table t1 ( id integer primary key, value real );
insert into t1 select generate_series( 1 , 1000000 ), random();

create table t2 ( id integer primary key, value real );
insert into t2 select generate_series( 1 , 1000000 ), random();

explain analyze select * from ( select * from t1 union all select * from t2 ) as a where id between  500000  and  600000  order by id;

                                                              QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost= 8684 . 53 .. 8708 . 31  rows= 9510  width= 8 ) (actual time= 602 . 041 .. 651 . 708  rows= 200002  loops= 1 )
   Sort Key: a.id
   ->  Append  (cost= 45 . 53 .. 7961 . 05  rows= 9510  width= 8 ) (actual time= 40 . 012 .. 322 . 554  rows= 200002  loops= 1 )
         ->  Bitmap Heap Scan on t1  (cost= 45 . 53 .. 3932 . 97  rows= 4755  width= 8 ) (actual time= 40 . 011 .. 106 . 799  rows= 100001  loops= 1 )
               Recheck Cond: ((id >=  500000 ) AND (id <=  600000 ))
               ->  Bitmap Index Scan on t1_pkey  (cost= 0 . 00 .. 45 . 53  rows= 4755  width= 0 ) (actual time= 39 . 879 .. 39 . 879  rows= 100001  loops= 1 )
                     Index Cond: ((id >=  500000 ) AND (id <=  600000 ))
         ->  Bitmap Heap Scan on t2  (cost= 45 . 53 .. 3932 . 97  rows= 4755  width= 8 ) (actual time= 27 . 921 .. 90 . 720  rows= 100001  loops= 1 )
               Recheck Cond: ((id >=  500000 ) AND (id <=  600000 ))
               ->  Bitmap Index Scan on t2_pkey  (cost= 0 . 00 .. 45 . 53  rows= 4755  width= 0 ) (actual time= 27 . 781 .. 27 . 781  rows= 100001  loops= 1 )
                     Index Cond: ((id >=  500000 ) AND (id <=  600000 ))
 Total runtime:  712 . 181  ms
( 12  rows)

set enable_bitmapscan to off;

explain analyze select * from ( select * from t1 union all select * from t2 ) as a where id between  500000  and  600000  order by id;

                                                             QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost= 13812 . 77 .. 13836 . 55  rows= 9510  width= 8 ) (actual time= 599 . 868 .. 651 . 721  rows= 200002  loops= 1 )
   Sort Key: a.id
   ->  Append  (cost= 0 . 00 .. 13089 . 29  rows= 9510  width= 8 ) (actual time= 0 . 042 .. 305 . 271  rows= 200002  loops= 1 )
         ->  Index Scan using t1_pkey on t1  (cost= 0 . 00 .. 6497 . 09  rows= 4755  width= 8 ) (actual time= 0 . 041 .. 95 . 048  rows= 100001  loops= 1 )
               Index Cond: ((id >=  500000 ) AND (id <=  600000 ))
         ->  Index Scan using t2_pkey on t2  (cost= 0 . 00 .. 6497 . 09  rows= 4755  width= 8 ) (actual time= 0 . 017 .. 100 . 931  rows= 100001  loops= 1 )
               Index Cond: ((id >=  500000 ) AND (id <=  600000 ))
 Total runtime:  715 . 789  ms
( 8  rows)

explain analyze select * from t1 join t2 using (id) order by id;

                                                            QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------
 Merge Join  (cost= 0 . 00 .. 60894 . 56  rows= 950988  width= 12 ) (actual time= 0 . 050 .. 3299 . 364  rows= 1000000  loops= 1 )
   Merge Cond: ("outer".id = "inner".id)
   ->  Index Scan using t1_pkey on t1  (cost= 0 . 00 .. 23314 . 87  rows= 950988  width= 8 ) (actual time= 0 . 014 .. 737 . 561  rows= 1000000  loops= 1 )
   ->  Index Scan using t2_pkey on t2  (cost= 0 . 00 .. 23314 . 87  rows= 950988  width= 8 ) (actual time= 0 . 027 .. 799 . 867  rows= 1000000  loops= 1 )
 Total runtime:  3558 . 723  ms
( 5  rows)
...
Рейтинг: 0 / 0
17.01.2007, 17:46
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34263349
Kruchinin Pahan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kruchinin Pahan
Участник
LeXa NalBatMergejoin в этом примере работает намного медленнее, чем sort. :-O Объяснить не могу, может быть выделение памяти...

Да нет. Все гораздо проще... Merge Join производит сортировку, используя два указателя, а Sort - один указатель. Соответственно, поиск первого меньшего и первого большего значения (для TimeStamp) занимает не 128 сдвигов по индексам, а 64 (в максимуме). То есть сортировка получается вдвое дешевле Merge. Хотя, индексы не сильно разряженные и реально количество сдвигов где-то 1-2 не более Ж;)
Append вообще физически в памяти ничего не перемещает, тока меняет пару-тройку указателей на блоки и (в данном случае) прицепляет ветку одного индекса к другому по первому битовому расхождению.

А Merge действительно не умеет неотсортировать результат. Иначе это не Merge, а какой-нибудь Hash.
Я полагаю таки, дело не в планах, дело в том, что движок посгреса плохо портируется под винду. К серваку еще никто не подцепился, а в памяти уже болтается 3 параллельных процесса. Общаться процессы могут либо через объекты ядра, либо через FileMapping. Каждый новый юзер - новый процесс. Для иксов это нормально, а вот винда слабовата с раздачей ресурсов процессам. К тому же винда не может обеспечить быстрого взаимодействия между ними. Вот и получается полный тормоз. Надо писать большой умный экзешник, который сам раздает задачи по потокам внутри одного процесса (как у MS). Тока это уже будет не Pg. Такая архитектура несколько более уязвима для падучей, чем нынешняя.
...
Рейтинг: 0 / 0
18.01.2007, 06:20
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34263357
Бабичев Сергей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бабичев Сергей
Участник
zsmКак получить план исполнения в текстовом, читабельном виде, так понять и не удалосьПочитай, может поможет:
Тынц - F.A.Q./Microsoft SQL Server/Настройка и конфигурация/Как получить план выполнения запроса в текстовом виде?
...
Рейтинг: 0 / 0
18.01.2007, 06:37
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34263831
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
Прошу прощения за ошибку в моем предыдущем посте - не наложил ограничение по id в join-запросе.

Новый тест:
Код: plaintext
1.
2.
3.
create table t1 ( id integer primary key, value integer );
insert into t1 select generate_series( 1 , 1000000 ),  1000000 *random();
create table t2 ( id integer primary key, value integer );
insert into t2 select generate_series( 1 , 1000000 ),  1000000 *random();

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
nalbat=> explain analyze select * from ( select * from t1 union all select * from t2 ) as a where id between  500000  and  600000  order by id;
                                                             QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost= 13812 . 77 .. 13836 . 55  rows= 9510  width= 8 ) (actual time= 524 . 369 .. 578 . 009  rows= 200002  loops= 1 )
   Sort Key: a.id
   ->  Append  (cost= 0 . 00 .. 13089 . 29  rows= 9510  width= 8 ) (actual time= 0 . 016 .. 258 . 601  rows= 200002  loops= 1 )
         ->  Index Scan using t1_pkey on t1  (cost= 0 . 00 .. 6497 . 09  rows= 4755  width= 8 ) (actual time= 0 . 016 .. 88 . 301  rows= 100001  loops= 1 )
               Index Cond: ((id >=  500000 ) AND (id <=  600000 ))
         ->  Index Scan using t2_pkey on t2  (cost= 0 . 00 .. 6497 . 09  rows= 4755  width= 8 ) (actual time= 0 . 020 .. 83 . 926  rows= 100001  loops= 1 )
               Index Cond: ((id >=  500000 ) AND (id <=  600000 ))
 Total runtime:  638 . 148  ms
( 8  rows)
Интересно, что оба! indexscan-на начинают отдавать строки наверх (append-у) сразу. (У них actual time minimum ~=0.) И append, что естественно, сразу же начинает отдавать это строки выше (sort-у). Означает ли это, что строки пришедшие на вход sort-у, находятся не в порядке t1, затем t2 (как мы думали), а в случайном порядке?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
nalbat=> explain analyze select * from ( select * from t1 union all select * from t2 ) as a where id between  500000  and  600000  order by value;
                                                             QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost= 13812 . 77 .. 13836 . 55  rows= 9510  width= 8 ) (actual time= 804 . 569 .. 859 . 572  rows= 200002  loops= 1 )
   Sort Key: a.value
   ->  Append  (cost= 0 . 00 .. 13089 . 29  rows= 9510  width= 8 ) (actual time= 0 . 020 .. 257 . 950  rows= 200002  loops= 1 )
         ->  Index Scan using t1_pkey on t1  (cost= 0 . 00 .. 6497 . 09  rows= 4755  width= 8 ) (actual time= 0 . 020 .. 80 . 856  rows= 100001  loops= 1 )
               Index Cond: ((id >=  500000 ) AND (id <=  600000 ))
         ->  Index Scan using t2_pkey on t2  (cost= 0 . 00 .. 6497 . 09  rows= 4755  width= 8 ) (actual time= 0 . 020 .. 85 . 346  rows= 100001  loops= 1 )
               Index Cond: ((id >=  500000 ) AND (id <=  600000 ))
 Total runtime:  941 . 552  ms
( 8  rows)
Видно, что "реальная" сортировка по value (тип integer) выполняется примерно в два раза дольше, чем сортировка по id (804-257=547ms versus 524-258=266ms), наверное из-за того что id уже "почти отсортированы". То есть сортировка по id получается более быстрой, чем обычная.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
nalbat=> explain analyze select * from t1 join t2 using (id) where t1.id between  500000  and  600000  and t2.id between  500000  and  600000  order by id;
                                                          QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------
 Merge Join  (cost= 0 . 00 .. 13018 . 20  rows= 24  width= 12 ) (actual time= 0 . 028 .. 370 . 526  rows= 100001  loops= 1 )
   Merge Cond: ("outer".id = "inner".id)
   ->  Index Scan using t1_pkey on t1  (cost= 0 . 00 .. 6497 . 09  rows= 4755  width= 8 ) (actual time= 0 . 013 .. 86 . 818  rows= 100001  loops= 1 )
         Index Cond: ((id >=  500000 ) AND (id <=  600000 ))
   ->  Index Scan using t2_pkey on t2  (cost= 0 . 00 .. 6497 . 09  rows= 4755  width= 8 ) (actual time= 0 . 010 .. 91 . 947  rows= 100001  loops= 1 )
         Index Cond: ((id >=  500000 ) AND (id <=  600000 ))
 Total runtime:  393 . 841  ms
( 7  rows)
Mergejoin выполняется примерно в 1.5 раза быстрее sort-а. Хотя это сравнение не совсем правильное, потому что append-запрос возвращет 200тыс строк (id,value), а join-запрос - 100тыс широких строк (id,t1.value,t2.value).
...
Рейтинг: 0 / 0
18.01.2007, 10:44
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34263867
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
Kruchinin Pahan... Merge Join производит сортировку ... А Merge действительно не умеет неотсортировать результат. ...Mergejoin ничего не сортирует. Он соединяет два отсортированных набора, а точнее говоря потока, пришедшие к нему на вход. Отсортированный набор на вход mergejoin-у может передать sort, indexscan, другой mergejoin, кто-нибудь еще. Вследствии этого выход (результат) mergejoin-а получается отсортированным.
...
Рейтинг: 0 / 0
18.01.2007, 10:52
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34263926
Kruchinin Pahan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kruchinin Pahan
Участник
LeXa NalBat Kruchinin Pahan... Merge Join производит сортировку ... А Merge действительно не умеет неотсортировать результат. ...Mergejoin ничего не сортирует. Он соединяет два отсортированных набора, а точнее говоря потока, пришедшие к нему на вход. Отсортированный набор на вход mergejoin-у может передать sort, indexscan, другой mergejoin, кто-нибудь еще. Вследствии этого выход (результат) mergejoin-а получается отсортированным.
Ну да. да. Согласен, неясно выразился. Действительно Merge работает с сортированными списками. И выход получается тоже сортированным в результате реализации Merge. Тока это нисколько не умаляет того, что работать приходится с двумя указателями.
...
Рейтинг: 0 / 0
18.01.2007, 11:03
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34265220
zsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zsm
Гость
И что в итоге мы видим: PG не умеет Merge-ить UNION ALL, что очевидно, было бы более эффективно, особенно для больших выборок.
...
Рейтинг: 0 / 0
18.01.2007, 15:00
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34265438
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
zsmPG не умеет Merge-ить UNION ALLВроде бы не умеет. Также это отсутствует в TODO . Но разработчики в курсе some kind of "Merge Sort" node . И это даже "является темой" для wish-list . :-)
...
Рейтинг: 0 / 0
18.01.2007, 15:41
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34265476
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
zsmчто очевидно, было бы более эффективно, особенно для больших выборок.Я бы сказал так: скорее всего, это было бы примерно в 1.5 раза быстрее, независимо от размера выборки.
...
Рейтинг: 0 / 0
18.01.2007, 15:49
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34265657
zsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zsm
Гость
LeXa NalBat zsmчто очевидно, было бы более эффективно, особенно для больших выборок.Я бы сказал так: скорее всего, это было бы примерно в 1.5 раза быстрее, независимо от размера выборки.

А почему не зависит от размера выборки?
Ведь чем больше выборка, тем больше придется сортировать.
Я слабо представляю, как реализована сортировка, но смею предположить, что по крайней мере все ключи придется сначала брать из таблиц и где-то их размещать.
Поправте, если я не прав...
...
Рейтинг: 0 / 0
18.01.2007, 16:37
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34265737
ездун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ездун
Гость
zsmНаверное, я бы и не стал связываться с PG, но слишком недешевое удовольствие - SQL2005.
Шибко на себестоимость продукта влияет ;-)
А из фриварных, кроме PG, другой достойной альтернативы просто не наблюдается.
Так что приходится как-то выкручиваться...
Вот 1С тоже так подумала и версию 8.1 выпустила по PG. Зайди к ним на сайтик - посмотри, качни их патчи. Заодно пролечиться и регистрозависимость в запросах (столкнетесь с этим после MSSQL). Настройку по умолчанию они там поменяли.
Или радуйтесь жизни вместе с MS и не дергайтесь.
...
Рейтинг: 0 / 0
18.01.2007, 16:53
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34265982
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
zsmА почему не зависит от размера выборки?
Ведь чем больше выборка, тем больше придется сортировать.В школе проходили, что merge - O(N), sort - O(N*log(N)). Но судя по тому, что сортировка по id работает существенно быстрее, чем по value, можно предположить, что сортировка по id будет O(N).

Провел эксперимент, из которого видно, что отношение времени sort к времени merge не зависит от N:
Код: 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.
explain analyze select * from ( select * from t1 union all select * from t2 ) as a where id between  500000  and  503000  order by id;
explain analyze select * from ( select * from t1 union all select * from t2 ) as a where id between  500000  and  510000  order by id;
explain analyze select * from ( select * from t1 union all select * from t2 ) as a where id between  500000  and  530000  order by id;
explain analyze select * from ( select * from t1 union all select * from t2 ) as a where id between  500000  and  600000  order by id;
explain analyze select * from ( select * from t1 union all select * from t2 ) as a where id between  500000  and  800000  order by id;

 17 . 796  ms
 58 . 001  ms
 172 . 974  ms
 599 . 509  ms
 1903 . 157  ms

explain analyze select * from t1 join t2 using (id) where t1.id between  500000  and  503000  and t2.id between  500000  and  503000  order by id;
explain analyze select * from t1 join t2 using (id) where t1.id between  500000  and  510000  and t2.id between  500000  and  510000  order by id;
explain analyze select * from t1 join t2 using (id) where t1.id between  500000  and  530000  and t2.id between  500000  and  530000  order by id;
explain analyze select * from t1 join t2 using (id) where t1.id between  500000  and  600000  and t2.id between  500000  and  600000  order by id;
explain analyze select * from t1 join t2 using (id) where t1.id between  500000  and  800000  and t2.id between  500000  and  800000  order by id;

 10 . 770  ms
 36 . 192  ms
 112 . 797  ms
 384 . 912  ms
 1109 . 669  ms

Отношение union sort time к merge join time:

 1 . 652 
 1 . 602 
 1 . 533 
 1 . 557 
 1 . 715

zsmЯ слабо представляю, как реализована сортировка, но смею предположить, что по крайней мере все ключи придется сначала брать из таблиц и где-то их размещать.Не знаю, как в постгресе реализована сортировка.
...
Рейтинг: 0 / 0
18.01.2007, 17:41
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34266132
zsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zsm
Гость
LeXa NalBat

Отношение union sort time к merge join time:
Код: plaintext
1.
2.
3.
4.
 1 . 652 
 1 . 602 
 1 . 533 
 1 . 557 
 1 . 715


А я попробовал выполнить запросы по всей таблице. У меня получилось:

select * from ( select * from t1 union all select * from t2 ) as a order by id;
~48c

select * from t1 join t2 using (id) order by id;
~24c

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

Наверное, на этом вопрос с эффективностью UNION ALL можно и закрыть.
Будем ждать и надеятся, что доработают.
...
Рейтинг: 0 / 0
18.01.2007, 18:17
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34266237
zsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zsm
Гость
А вот еще один пример:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select * from t1 join t2 ON (t1.id = t2.id) where t1.id between  500000  and  600000  order by t1.id;

"Merge Join  (cost=0.00..39304.25 rows=99678 width=16) (actual time=726.699..1201.091 rows=100001 loops=1)"
"  Merge Cond: (t1.id = t2.id)"
"  ->  Index Scan using t1_pkey on t1  (cost=0.00..4171.10 rows=99687 width=8) (actual time=0.077..106.977 rows=100001 loops=1)"
"        Index Cond: ((id >= 500000) AND (id <= 600000))"
"  ->  Index Scan using t2_pkey on t2  (cost=0.00..31388.04 rows=999912 width=8) (actual time=0.106..551.512 rows=600001 loops=1)"
"Total runtime: 1255.998 ms"
Не умеет планировщик сам переносить фильтр с поля t1.id на t2.id для таких простых и очень частых случаев.
Приходится все делать руками.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select * from t1 join t2 ON (t1.id = t2.id) where t1.id between  500000  and  600000  and t2.id between  500000  and  600000  order by t1.id;

"Merge Join  (cost=0.00..8545.29 rows=10298 width=16) (actual time=0.282..385.696 rows=100001 loops=1)"
"  Merge Cond: (t1.id = t2.id)"
"  ->  Index Scan using t1_pkey on t1  (cost=0.00..4171.10 rows=99687 width=8) (actual time=0.156..83.807 rows=100001 loops=1)"
"        Index Cond: ((id >= 500000) AND (id <= 600000))"
"  ->  Index Scan using t2_pkey on t2  (cost=0.00..3764.40 rows=103302 width=8) (actual time=0.114..83.032 rows=100001 loops=1)"
"        Index Cond: ((id >= 500000) AND (id <= 600000))"
"Total runtime: 436.843 ms"

А вот MS умеет.
...
Рейтинг: 0 / 0
18.01.2007, 18:44
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34266642
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
zsmА я попробовал выполнить запросы по всей таблице. У меня получилось:

select * from ( select * from t1 union all select * from t2 ) as a order by id;
~48c

select * from t1 join t2 using (id) order by id;
~24c

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

zsmВообще, для меня все кажется очевидным.
Мало того, что сортировка требует времени и ресурсов (например, если клиентский запрос упирается в квоту по памяти, то это еще сильнее усугубит дело),
еще один большой минус я вижу в существенной задержке в полчении первой записи - пока все не отсортирует, ничего ведь не вернет.Верно, не вернет. (Для sort-плана actual_time_first_row = 524.369.)

zsmНаверное, на этом вопрос с эффективностью UNION ALL можно и закрыть.
Будем ждать и надеятся, что доработают.Можно не только ждать, но написать письмо с просьбой в список рассылки .

zsmНе умеет планировщик сам переносить фильтр с поля t1.id на t2.id для таких простых и очень частых случаев. Приходится все делать руками.Да, я очень этому удивился. ИМХО, планировщик тут откровенно тупит. Еще одна тема для списка рассылки. :-)
...
Рейтинг: 0 / 0
18.01.2007, 23:56
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34267443
vfabr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vfabr
Гость
мне подарили новую шкоду (автомобиль) он ездит впринципе хорошо но не так хорошо как бмв 7. и салон у него не такой хороший как у бмв. и электроники мало и и и и и и и !

но бмв дорогая примерно штук 100 баксов а шкоду подарили. нет можно бмв украсть и наслаждаться бесплатно всеми ее плюсами, но красть страшновато! но шкода плохо ездит по сравнению с бмв и не такая красивая .... но зато бмв стоит 100 штук.
...
Рейтинг: 0 / 0
19.01.2007, 11:31
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34267696
Shweik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shweik
Участник
Честно говоря сразу хотелось подобным образовы выразиться и закрыть эти слезливые топики....
IMHO с _таким_ вопросами одначначно нужно в pg_users писать.
Вообще могу сказать что 8.2.1 меня лично не впечатлил. Что релиз что снапшот на притивных тестах (да взять хотя бы пример с которого этот топ начат) почему-то отстают от 8.1.3/4 Одна и таже коробка с ОС только что созданный кластер базы и разница во времени выполенения до 200ms!
Причем что на дефолтных установках что на рихтованных разрыв заметный и однозначно не в пользу
свежака.
Понятно что это еще ничего не значит но думаю поднимать версию смысла нет.
Возможно все таки
в погоне за новыми фичам чего-то в очередной раз упестили и выправиться это в нечетной версии. 8-)
Если у кого есть возможность/желание попробуйте выполнить скрипты приведенные в первом посте на
PG 8.1.3/PG 8.1.4/PG 8.2.1
и давайте сравним результаты.
А меряться пи...планами с M$ и Oracle - милости прошу в "Сравнение БД". 8-)
...
Рейтинг: 0 / 0
19.01.2007, 12:26
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34268228
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
ShweikЧестно говоря сразу хотелось подобным образовы выразиться и закрыть эти слезливые топики....Этот топик конструктивный, с конкретным вопросом, потребовавшим разбирательства, закрыть его было бы неправильно.
...
Рейтинг: 0 / 0
19.01.2007, 14:16
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34268430
Shweik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shweik
Участник
IMHO если и дальше будут сравнивать планировщики
SQL2005 и PG - этому топику здесь не место.
...
Рейтинг: 0 / 0
19.01.2007, 14:53
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34268492
zsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zsm
Гость
ShweikIMHO если и дальше будут сравнивать планировщики
SQL2005 и PG - этому топику здесь не место.

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

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

Подскажите, неужели у PostgressSQL все так запущено или надо что-то подкрутить?
Комп - PIII 866, 512 RAM.
...
Рейтинг: 0 / 0
09.02.2007, 16:02
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34319994
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
09.02.2007, 16:29
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34320092
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
Yuriy Yurchenkoзапрос select count(id) from blablabla отрабатывается в течение от 35 до 46 секунд!!!count по всей таблице долго обсуждали тут
...
Рейтинг: 0 / 0
09.02.2007, 17:02
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34320145
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Andrey DaeronИли, например, не совсем честная реализация count() в FireBird'е - будет тоже быстрее.
и в чем же ее нечестность? Реализация абсолютно аналогичная PGSQL'ной, с теми же недостатками.
...
Рейтинг: 0 / 0
09.02.2007, 17:20
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34320190
Shweik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
09.02.2007, 17:34
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34320309
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
dimitr Andrey DaeronИли, например, не совсем честная реализация count() в FireBird'е - будет тоже быстрее.
и в чем же ее нечестность? Реализация абсолютно аналогичная PGSQL'ной, с теми же недостатками.
Где-то на этом форме читал про ее неатомарность, за счет использования индексов которые живут ессно вне транзакций. Т.е. есть транзация которая вставляет по 1000 записей и их комитит, и есть другая которая говорит count(). Есть ситуации, при которых в count() будет кол-во записей не кратное 1000. ИМХО это было про 1.5х версию. Опять же с подробностями - не сюда, а к фаербердистам.
...
Рейтинг: 0 / 0
09.02.2007, 18:16
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34320697
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Andrey DaeronГде-то на этом форме читал про ее неатомарность, за счет использования индексов которые живут ессно вне транзакций. Т.е. есть транзация которая вставляет по 1000 записей и их комитит, и есть другая которая говорит count(). Есть ситуации, при которых в count() будет кол-во записей не кратное 1000
неатомарность может иметь место, но эта тема не связана с данной :-) Реализация индексов в FB очень схожа с PG'шной: ID тр-ции не включается в ключ, поэтому только индексным покрытием никакой запрос не решается - надо читать саму запись. И count() работает там абсолютно идентично.
...
Рейтинг: 0 / 0
09.02.2007, 22:36
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34320787
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
10.02.2007, 00:05
| Ответить | Цитировать | Написать  
PGSQL. Разочарование близко 2.
    #34324562
Shweik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shweik
Участник
LeXa NalBat2 Shweik.

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

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

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

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


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