Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / PGSQL. Разочарование близко 2. / 25 сообщений из 43, страница 1 из 2
  1  все
16.01.2007, 22:19
    #34260112
zsm
zsm
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
Вот один из простеньких примеров, который призван продемонстрировать некоторую "недалекость" планировщика.

Создаем 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
| Ответить | Цитировать | Написать  
17.01.2007, 00:07
    #34260194
СергейК
СергейК
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
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, 10:27
    #34260727
st_serg
st_serg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
в oracle9i план аналогичный
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.01.2007, 10:47
    #34260801
Andrey Daeron
Andrey Daeron
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
zsmВот один из простеньких примеров, который призван продемонстрировать некоторую "недалекость" планировщика.

Кста, а в SQL2005 какой план?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.01.2007, 16:01
    #34262190
zsm
zsm
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
авторКста, а в 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:37
    #34262320
Andrey Daeron
Andrey Daeron
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
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, 17:10
    #34262458
Funny_Falcon
Funny_Falcon
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
авторНу в принципе да, только не понятно (по плану) будет ли произведена сортировка результата вообще. И если да, то когда - Clust. index scan - это никак не сортировка. Merj Join - тоже.

Merge Join - это упорядоченное слияние упорядоченных наборов. Т.е. результирующий набор будет отсортирован.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.01.2007, 17:15
    #34262475
zsm
zsm
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
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:46
    #34262619
LeXa NalBat
LeXa NalBat
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
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
| Ответить | Цитировать | Написать  
18.01.2007, 06:20
    #34263349
Kruchinin Pahan
Kruchinin Pahan
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
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:37
    #34263357
Бабичев Сергей
Бабичев Сергей
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
zsmКак получить план исполнения в текстовом, читабельном виде, так понять и не удалосьПочитай, может поможет:
Тынц - F.A.Q./Microsoft SQL Server/Настройка и конфигурация/Как получить план выполнения запроса в текстовом виде?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.01.2007, 10:44
    #34263831
LeXa NalBat
LeXa NalBat
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
Прошу прощения за ошибку в моем предыдущем посте - не наложил ограничение по 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:52
    #34263867
LeXa NalBat
LeXa NalBat
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
Kruchinin Pahan... Merge Join производит сортировку ... А Merge действительно не умеет неотсортировать результат. ...Mergejoin ничего не сортирует. Он соединяет два отсортированных набора, а точнее говоря потока, пришедшие к нему на вход. Отсортированный набор на вход mergejoin-у может передать sort, indexscan, другой mergejoin, кто-нибудь еще. Вследствии этого выход (результат) mergejoin-а получается отсортированным.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.01.2007, 11:03
    #34263926
Kruchinin Pahan
Kruchinin Pahan
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
LeXa NalBat Kruchinin Pahan... Merge Join производит сортировку ... А Merge действительно не умеет неотсортировать результат. ...Mergejoin ничего не сортирует. Он соединяет два отсортированных набора, а точнее говоря потока, пришедшие к нему на вход. Отсортированный набор на вход mergejoin-у может передать sort, indexscan, другой mergejoin, кто-нибудь еще. Вследствии этого выход (результат) mergejoin-а получается отсортированным.
Ну да. да. Согласен, неясно выразился. Действительно Merge работает с сортированными списками. И выход получается тоже сортированным в результате реализации Merge. Тока это нисколько не умаляет того, что работать приходится с двумя указателями.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.01.2007, 15:00
    #34265220
zsm
zsm
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
И что в итоге мы видим: PG не умеет Merge-ить UNION ALL, что очевидно, было бы более эффективно, особенно для больших выборок.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.01.2007, 15:41
    #34265438
LeXa NalBat
LeXa NalBat
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
zsmPG не умеет Merge-ить UNION ALLВроде бы не умеет. Также это отсутствует в TODO . Но разработчики в курсе some kind of "Merge Sort" node . И это даже "является темой" для wish-list . :-)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.01.2007, 15:49
    #34265476
LeXa NalBat
LeXa NalBat
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
zsmчто очевидно, было бы более эффективно, особенно для больших выборок.Я бы сказал так: скорее всего, это было бы примерно в 1.5 раза быстрее, независимо от размера выборки.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.01.2007, 16:37
    #34265657
zsm
zsm
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
LeXa NalBat zsmчто очевидно, было бы более эффективно, особенно для больших выборок.Я бы сказал так: скорее всего, это было бы примерно в 1.5 раза быстрее, независимо от размера выборки.

А почему не зависит от размера выборки?
Ведь чем больше выборка, тем больше придется сортировать.
Я слабо представляю, как реализована сортировка, но смею предположить, что по крайней мере все ключи придется сначала брать из таблиц и где-то их размещать.
Поправте, если я не прав...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.01.2007, 16:53
    #34265737
ездун
ездун
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
zsmНаверное, я бы и не стал связываться с PG, но слишком недешевое удовольствие - SQL2005.
Шибко на себестоимость продукта влияет ;-)
А из фриварных, кроме PG, другой достойной альтернативы просто не наблюдается.
Так что приходится как-то выкручиваться...
Вот 1С тоже так подумала и версию 8.1 выпустила по PG. Зайди к ним на сайтик - посмотри, качни их патчи. Заодно пролечиться и регистрозависимость в запросах (столкнетесь с этим после MSSQL). Настройку по умолчанию они там поменяли.
Или радуйтесь жизни вместе с MS и не дергайтесь.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.01.2007, 17:41
    #34265982
LeXa NalBat
LeXa NalBat
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
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, 18:17
    #34266132
zsm
zsm
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
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:44
    #34266237
zsm
zsm
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
А вот еще один пример:

Код: 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, 23:56
    #34266642
LeXa NalBat
LeXa NalBat
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
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
| Ответить | Цитировать | Написать  
19.01.2007, 11:31
    #34267443
vfabr
vfabr
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
мне подарили новую шкоду (автомобиль) он ездит впринципе хорошо но не так хорошо как бмв 7. и салон у него не такой хороший как у бмв. и электроники мало и и и и и и и !

но бмв дорогая примерно штук 100 баксов а шкоду подарили. нет можно бмв украсть и наслаждаться бесплатно всеми ее плюсами, но красть страшновато! но шкода плохо ездит по сравнению с бмв и не такая красивая .... но зато бмв стоит 100 штук.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.01.2007, 12:26
    #34267696
Shweik
Shweik
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PGSQL. Разочарование близко 2.
Честно говоря сразу хотелось подобным образовы выразиться и закрыть эти слезливые топики....
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
| Ответить | Цитировать | Написать  
  1  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / PGSQL. Разочарование близко 2. / 25 сообщений из 43, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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