powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Быстрый подсчет distinct values по индексированным полям
21 сообщений из 21, страница 1 из 1
Быстрый подсчет distinct values по индексированным полям
    #37453479
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Читая форумы я натолкнулся на факт что Mysql умеет использовать индексы для поиска уникальных значений.
И в принципе это логично если уникальных значений не много.

PostgreSQL так не умеет.
Подсчет уникальных значений в большой таблице достаточно частый головняк для Postgresql DBA так как любит тормозить.
Пришлось обьяснять.

(настройки по умолчанию кроме work_mem 32MB / shared_buffers 2GB).

Подготовка данных:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
DROP TABLE IF EXISTS test_table;
CREATE table test_table(low_cardinality integer, medium_cardinality integer, high_cardinality integer, very_high_cardinality integer);
INSERT into test_table select (random()* 10 )::integer, (random()* 100 )::integer, (random()* 10000 )::integer, (random()* 1000000 )::integer from generate_series( 1 , 10000000 );
create index test_table_low_cardinality_key on test_table(low_cardinality);
create index test_table_medium_cardinality_key on test_table(medium_cardinality);
create index test_table_high_cardinality_key on test_table(high_cardinality);
create index test_table_very_high_cardinality_key on test_table(very_high_cardinality);
analyze test_table;


Теперь смотрим на скорость select count(distinct ...) from test_table
(select distinct будет иметь туже приблизительно скорость):
(все тесты проводились 3-4 раза для контроля стабильности результатов)

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
select count(distinct low_cardinality) from test_table;
 count
-------
     11 
Time:  25656 , 434  ms

select count(distinct medium_cardinality) from test_table;
 count
-------
    101 
Time:  30456 , 120  ms

select count(distinct high_cardinality) from test_table;
 count
-------
  10001 
Time:  32730 , 315  ms

select count(distinct very_high_cardinality) from test_table;
 count
--------
  999961 
Time:  34082 , 421  ms

На выходе имеем 25+ секунд на любой вариант с замедлением при росте количества уникальных значений.

Теперь быстрая реализация использующая индексы по полям и рекурсивный запрос:

Код: 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.
WITH RECURSIVE collector(field) AS (
      SELECT min(low_cardinality) FROM test_table
      UNION ALL
      SELECT * FROM (
          SELECT (SELECT test_table.low_cardinality FROM test_table WHERE test_table.low_cardinality>collector.field ORDER BY test_table.low_cardinality LIMIT  1 ) as field
          FROM collector
          ORDER BY collector.field DESC LIMIT  1 
      ) _  WHERE field IS NOT NULL
)
SELECT count(*) FROM collector;
 count
-------
     11 
Time:  1 , 100  ms
Итого в  30000  раз быстрее :)

WITH RECURSIVE collector(field) AS (
      SELECT min(medium_cardinality) FROM test_table
      UNION ALL
      SELECT * FROM (
          SELECT (SELECT test_table.medium_cardinality FROM test_table WHERE test_table.medium_cardinality>collector.field ORDER BY test_table.medium_cardinality LIMIT  1 ) as field
          FROM collector
          ORDER BY collector.field DESC LIMIT  1 
      ) _  WHERE field IS NOT NULL
)
SELECT count(*) FROM collector;
 count
-------
    101 
Time:  4 , 734  ms
Итого почти в  8000  раз быстрее.


WITH RECURSIVE collector(field) AS (
      SELECT min(high_cardinality) FROM test_table
      UNION ALL
      SELECT * FROM (
          SELECT (SELECT test_table.high_cardinality FROM test_table WHERE test_table.high_cardinality>collector.field ORDER BY test_table.high_cardinality LIMIT  1 ) as field
          FROM collector
          ORDER BY collector.field DESC LIMIT  1 
      ) _  WHERE field IS NOT NULL
)
SELECT count(*) FROM collector;
 count
-------
  10001 
Time:  335 , 375  ms
Итого в  100  раз быстрее


WITH RECURSIVE collector(field) AS (
      SELECT min(very_high_cardinality) FROM test_table
      UNION ALL
      SELECT * FROM (
          SELECT (SELECT test_table.very_high_cardinality FROM test_table WHERE test_table.very_high_cardinality>collector.field ORDER BY test_table.very_high_cardinality LIMIT  1 ) as field
          FROM collector
          ORDER BY collector.field DESC LIMIT  1 
      ) _  WHERE field IS NOT NULL
)
SELECT count(*) FROM collector;
 count
--------
  999961 
Time:  32106 , 819  ms
Итого баш на баш.

В итоге получена реализация distinct которая эффективно использует индексы по полю и в случаях не слишком большого количества уникальных значений работает принципиально быстрее.
Я кстати ожидал квадратичной деградации этого алгоритма... но на практике наблюдается линейная (база оказалась умнее чем я ожидал).

Собственно запрос для тех кто знает как работает WITH RECURSIVE простой.
Все сложности только с обходом ограничений на то что можно использовать с WITH RECURSIVE а что нельзя
(нельзя: аггрегаты и подзапросы по накопительной таблице).

PS: 8.4+ only естественно.

PPS: если непонятно как оно устроено пишите я попробую более подробно обьяснить.

PPPS: аналогично можно реализовать эффективные запросы вида
select max(cdate),status from big_table group by status и подобные им


<BR>--<BR>Проект с базой но без DBA всеравно что автопарк без штатного автомеханика. Ездит пока все не сломается.<BR> http://mboguk.moikrug.ru
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #37453549
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk,

гут)
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #37453709
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk Я кстати ожидал квадратичной деградации этого алгоритма... но на практике наблюдается линейная (база оказалась умнее чем я ожидал).насколько я помню свои тесты - оно только поначалу линейно.
а с некоторого порога резко лезет вверх.
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #37453778
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk,

немного переписал

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
with recursive

  xx( x ) as
  (
    select ( select medium_cardinality from tmp.test_table order by medium_cardinality limit  1  )
    
    union all

    select ( select medium_cardinality from tmp.test_table where medium_cardinality > x order by medium_cardinality limit  1  ) from xx where x notnull

    -- тут рекурсия пока нул не получим, то есть пока будем находить следующее новое значение

  )
  
select * from xx where x notnull -- нам не нужен "остановочный" нул


деградация линейная от кол-ва различных элементов. а внутри этой линии логарифм от размера таблицы
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #37453794
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwq,

тут лезть РЕЗКО вверх может только, если у вас где то памяти какой-то не хватило.

а так всё довольно гладко

k * lg( N )

k - кол-во различных
N - размер таблицы
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #37453995
Фотография Ёш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хотел предложить добавить на wiki, но там уже есть %) http://wiki.postgresql.org/wiki/Loose_indexscan
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #37454091
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЁшХотел предложить добавить на wiki, но там уже есть %) http://wiki.postgresql.org/wiki/Loose_indexscan

черт все придумано до нас...
интересно почему я раньше этой ссылки не видел
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #37454157
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Misha Tyurinqwwq,

тут лезть РЕЗКО вверх может только, если у вас где то памяти какой-то не хватило.

а так всё довольно гладко

k * lg( N )

k - кол-во различных
N - размер таблицы
вспомнил.
немного другой случай смотрел :0)
/topic/876457&pg=1&hl=recursive

- из-за чего там лезло - не помню.

да, и еще забавно было, помню, если в рекурсивном запросе брать не всю work_table (1 запись на каждой иттерации), а _специально_ сказать только LIMIT 1 - то EXPLAIN ANALYZE много быстрее получался. а вот насчет реальной скорости запросов не помню.
точно не вспомню, надо смотреть записнушки.
вот примерно скажем если в стартовом примере автора этого треда сделать
Код: plaintext
         FROM collector\n          --ORDER BY collector.field DESC LIMIT 1\n
- то получим те же времена и числа. - work_table однозаписна на каждой итерации.
а вот в том случае - сильно менялась цена, хотя work_table тоже была однозаписна на каждой итерации.

ЗЫ а про индексы для свёртки уникальных - надо просто посмотреть на индекс как на отдельную (и _полную_) таблицу ключей - и сразу станет понятно, что и как считать уже имеющимися у оптимайзера методами 11318626. не понимаю, почему не сделано.
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #37454237
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwqMisha Tyurinqwwq,

тут лезть РЕЗКО вверх может только, если у вас где то памяти какой-то не хватило.

а так всё довольно гладко

k * lg( N )

k - кол-во различных
N - размер таблицы
вспомнил.
немного другой случай смотрел :0)
/topic/876457&pg=1&hl=recursive

- из-за чего там лезло - не помню.



а там лезло из-за того, что там другая, уже не линейная зависимость. и при "дальних" сканах уже много индекса перебирается.

там

k^2 * log(N)
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #37454243
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot qwwq]Misha Tyurinqwwq,

ЗЫ а про индексы для свёртки уникальных - надо просто посмотреть на индекс как на отдельную (и _полную_) таблицу ключей - и сразу станет понятно, что и как считать уже имеющимися у оптимайзера методами 11318626 . не понимаю, почему не сделано.

потому что индекс - это не таблица. MVCC тут у нас такой.

можно явно, на триггерах например, поддерживать аналогичные структуры и денормализацию подобную в целом
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #37454419
склероз
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Misha Tyurin а там лезло из-за того, что там другая, уже не линейная зависимость. и при "дальних" сканах уже много индекса перебирается.

там

k^2 * log(N)это я тогда вычислил
/*быстро наступает инфляция новых значений*/
- но забыл.
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #37454428
Misha Tyurinпотому что индекс - это не таблица. MVCC тут у нас такой.

можно явно, на триггерах например, поддерживать аналогичные структуры и денормализацию подобную в целома нам нужны не актуальные значения, а заведомо накрывающее мн-во значений. это что касаемо транзакционности [и не версионности индексов ]. избыточность нам не мешает (вернее не принципиально - только на скорость)

а что касается скорости вычитки мн-ва значений (а не мн-ва всех адресов) малоселективного индекса - я думаю это много быстрее, хотя помню с трудом способы организации/читки индексного дерева - смотрел только в общих чертах.

PS что касается поддержания - то как правило в нормально спроектированной базе все эти таблицы "ключей" всегда существуют. в виде т.н. справочников и fk гарантию их накрытия контролирует. т.е. их даже не надо триггерно поддерживать.
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
Быстрый подсчет distinct values по индексированным полям
    #38276010
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim Boguk,
Здесь
выбор строк с уникальной группой полей
Вы советовали использовать для группы этот же метод. Не моглы бы Вы привести пример для группы полей.
Спасибо.
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #38276324
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gold_Maxim Boguk,
Здесь
выбор строк с уникальной группой полей
Вы советовали использовать для группы этот же метод. Не моглы бы Вы привести пример для группы полей.
Спасибо.

так тоже самое по сути:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
WITH RECURSIVE
xx(x) AS
(
  select ( select test_table from test_table order by a,b,c limit 1 )
  union all
  select ( select test_table from test_table where (a,b,c) > ((x).a, (x).b, (x).c) order by a,b,c limit 1 ) from xx where x is not null
)  
select (x).* from xx where x is not null

 -- нам не нужен "остановочный" нул



тут предполагается что a,b,c все not null иначе не понятно какой там distinct должен быть (считать ли nulls равными или нет)
ну и естественно индекс по a,b,c нужен

тестирование:
на 9.2 еще и index only scan во всю силу работает:

Код: 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.
mboguk=# create table test_table(a integer not null, b integer not null, c integer not null);
CREATE TABLE
mboguk=# insert into test_table select random()*10::integer, random()*10::integer, random()*10::integer from generate_series(1,1000000);
INSERT 0 1000000
mboguk=# create index test_index on test_table(a,b,c);
CREATE INDEX
mboguk=# vacuum ANALYZE test_table;
VACUUM
mboguk=# explain analyze WITH RECURSIVE
xx(x) AS
(
  select ( select test_table from test_table order by a,b,c limit 1 )
  union all
  select ( select test_table from test_table where (a,b,c) > ((x).a, (x).b, (x).c) order by a,b,c limit 1 ) from xx where x is not null
)
select (x).* from xx where x is not null
;
                                                                           QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------
 CTE Scan on xx  (cost=14.33..16.35 rows=100 width=32) (actual time=0.120..174.800 rows=1331 loops=1)
   Filter: (x IS NOT NULL)
   Rows Removed by Filter: 1
   CTE xx
     ->  Recursive Union  (cost=0.05..14.33 rows=101 width=32) (actual time=0.101..155.561 rows=1332 loops=1)
           ->  Result  (cost=0.05..0.06 rows=1 width=0) (actual time=0.090..0.096 rows=1 loops=1)
                 InitPlan 1 (returns $1)
                   ->  Limit  (cost=0.00..0.05 rows=1 width=48) (actual time=0.061..0.067 rows=1 loops=1)
                         ->  Index Scan using test_index on test_table  (cost=0.00..51947.31 rows=1000000 width=48) (actual time=0.044..0.044 rows=1 loops=1)
           ->  WorkTable Scan on xx  (cost=0.00..1.22 rows=10 width=32) (actual time=0.089..0.096 rows=1 loops=1332)
                 Filter: (x IS NOT NULL)
                 Rows Removed by Filter: 0
                 SubPlan 2
                   ->  Limit  (cost=0.00..0.10 rows=1 width=48) (actual time=0.058..0.064 rows=1 loops=1331)
                         ->  Index Scan using test_index on test_table  (cost=0.00..32488.84 rows=333333 width=48) (actual time=0.041..0.041 rows=1 loops=1331)
                               Index Cond: (ROW(a, b, c) > ROW((xx.x).a, (xx.x).b, (xx.x).c))
 Total runtime: 182.060 ms

vs

mboguk=# explain analyze select distinct * from test_table;
                                                          QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=22906.00..22919.31 rows=1331 width=12) (actual time=11512.108..11520.078 rows=1331 loops=1)
   ->  Seq Scan on test_table  (cost=0.00..15406.00 rows=1000000 width=12) (actual time=0.027..6173.637 rows=1000000 loops=1)
 Total runtime: 11525.688 ms

ускорение в 100 раз при 1331 уникальных значениях в таблице на миллион записей... чем больше таблица и чем меньше distinct values - тем будет быстрее...

если таблица широкая и полей в ней много то лучше поставить hstore и сделать чуть по другому:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
WITH RECURSIVE
xx(x) AS
(
  select ( select hstore(ARRAY['a',a::text,'b',b::text,'c',c::text]) from test_table order by a,b,c limit 1 )
  union all
  select ( select hstore(ARRAY['a',a::text,'b',b::text,'c',c::text]) from test_table where (a,b,c) > ((x->'a')::integer, (x->'b')::integer, (x->'c')::integer) order by a,b,c limit 1 ) from xx where x is not null
)  
select (x->'a')::integer, (x->'b')::integer, (x->'c')::integer from xx where x is not null



Код: 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.
mboguk=# explain analyze WITH RECURSIVE
xx(x) AS
(
  select ( select hstore(ARRAY['a',a::text,'b',b::text,'c',c::text]) from test_table order by a,b,c limit 1 )
  union all
  select ( select hstore(ARRAY['a',a::text,'b',b::text,'c',c::text]) from test_table where (a,b,c) > ((x->'a')::integer, (x->'b')::integer, (x->'c')::integer) order by a,b,c limit 1 ) from xx where x is not null
)
select (x->'a')::integer, (x->'b')::integer, (x->'c')::integer from xx where x is not null
;
                                                                             QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
 CTE Scan on xx  (cost=11.87..16.14 rows=100 width=32) (actual time=0.204..163.935 rows=1331 loops=1)
   Filter: (x IS NOT NULL)
   Rows Removed by Filter: 1
   CTE xx
     ->  Recursive Union  (cost=0.05..11.87 rows=101 width=32) (actual time=0.164..143.777 rows=1332 loops=1)
           ->  Result  (cost=0.05..0.06 rows=1 width=0) (actual time=0.143..0.154 rows=1 loops=1)
                 InitPlan 1 (returns $1)
                   ->  Limit  (cost=0.00..0.05 rows=1 width=12) (actual time=0.096..0.107 rows=1 loops=1)
                         ->  Index Only Scan using test_index on test_table  (cost=0.00..47912.40 rows=1000000 width=12) (actual time=0.074..0.074 rows=1 loops=1)
                               Heap Fetches: 0
           ->  WorkTable Scan on xx  (cost=0.00..0.98 rows=10 width=32) (actual time=0.083..0.089 rows=1 loops=1332)
                 Filter: (x IS NOT NULL)
                 Rows Removed by Filter: 0
                 SubPlan 2
                   ->  Limit  (cost=0.03..0.08 rows=1 width=12) (actual time=0.057..0.063 rows=1 loops=1331)
                         ->  Index Only Scan using test_index on test_table  (cost=0.03..16807.09 rows=333333 width=12) (actual time=0.041..0.041 rows=1 loops=1331)
                               Index Cond: (ROW(a, b, c) > ROW(((xx.x -> 'a'::text))::integer, ((xx.x -> 'b'::text))::integer, ((xx.x -> 'c'::text))::integer))
                               Heap Fetches: 0
 Total runtime: 170.443 ms

Скорость не хуже чем у первого варианта но всегда гарантированный index only scan
А на широкой таблице легко может быть раз в 10 быстрее даже...
Но писать конечно менее удобно.

Как то так.

--
Maxim Boguk
Senior Postgresql DBA
http://www.postgresql-consulting.ru/
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #38276797
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim Boguk,

Спасибо!!!
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
Быстрый подсчет distinct values по индексированным полям
    #40061113
kliff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk,

Максим, тема старая, но хотел бы спросить.

например у меня одна таблица с уникальным id 15000 записей

и вторая таблица, в которой каждому id соответствуют тысячи id_org 4млн записей


я делаю select distinct t1.id, t2.id_org, t1.name, t1.status, t1.second_name from table1 t1 join table2 t2 on t2.t1_id=t1.id получаю 1млн записей

делается по факту distinct 4млн записей


Скажите, можно ли сюда приделать ваш способ и им выбирать уникальные t2.id_org для каждого t1.id?
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #40061130
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kliff
Maxim Boguk,

Максим, тема старая, но хотел бы спросить.

например у меня одна таблица с уникальным id 15000 записей

и вторая таблица, в которой каждому id соответствуют тысячи id_org 4млн записей


я делаю select distinct t1.id, t2.id_org, t1.name, t1.status, t1.second_name from table1 t1 join table2 t2 on t2.t1_id=t1.id получаю 1млн записей

делается по факту distinct 4млн записей


Скажите, можно ли сюда приделать ваш способ и им выбирать уникальные t2.id_org для каждого t1.id?


Не понял вашего описания задачи... вы бы хоть таблицы обьявили...
я даже не могу написать запрос который бы прояснил бы ситуацию на счет стоит или нет...
В общем случае если вы смотрели на пост - на миллионе distinct значений уже толку нет особо.
Особенно если на входе 4М а на выходе 1М (было бы на входе 400М а на выходе 1M - ситуация была бы другая).


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #40061158
kliff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk,

вот все описание select distinct t1.id, t2.id_org, t1.name, t1.status, t1.second_name from table1 t1 join table2 t2 on t2.t1_id=t1.id

вопрос можно ли сделать через рекурсию, ведь дубли только в table2
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #40061160
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kliff
Maxim Boguk,

вот все описание select distinct t1.id, t2.id_org, t1.name, t1.status, t1.second_name from table1 t1 join table2 t2 on t2.t1_id=t1.id

вопрос можно ли сделать через рекурсию, ведь дубли только в table2


ну так оно очевидно же переписывается в distinct по одной таблице где дубли

select t1.id, t2.id_org, t1.name, t1.status, t1.second_name from table1 t1
join (select distinct t1_id, id_org FROM table2) AS t2 on t2.t1_id=t1.id

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #40061306
kliff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk, да, так пробовал. результат по скорости не устраивает, но возможно это максимум что можно сделать.
...
Рейтинг: 0 / 0
Быстрый подсчет distinct values по индексированным полям
    #40061357
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kliff
Maxim Boguk, да, так пробовал. результат по скорости не устраивает, но возможно это максимум что можно сделать.


Смотря что именно вы делали... такой distinct или его оптимизацию по вышеописанному треду?
(прочем при 1 уникальном на 4 строки - толку 100% не будет... надо хотя бы 1 к 100 чтобы толк был).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
21 сообщений из 21, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Быстрый подсчет distinct values по индексированным полям
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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