ReSQL.ru
     
powered by simpleCommunicator - 2.0.56     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / Вопросы на собеседовании
24 сообщений из 149, страница 6 из 6
  6  все
Вопросы на собеседовании
    #39760598
niteshade
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
niteshade
Гость
ОзверинniteshadeОзверин,
Пожалуйста, посмотрите на запрос на удаление дубликатов в самом первом посте темы.
Он правильный. Зачем уже четвёртую страницу вы его неправильно переписываете?

не, он неправильный.

Можно по шагам разобрать:

Код: sql
1.
SELECT max(id) FROM table GROUP BY name HAVING count(id)>1


выбрать записи с максимальным id, если эти записи имеют более 1го дупликата по полю name

Код: sql
1.
2.
DELETE FROM table
WHERE id NOT IN(...)


удалить все остальные записи.

То есть те записи, которые НЕ дублируются, будут удалены, останутся только дубликаты с максимальным айди - все наоборот же.
да, был невнимателен
правильный:
Код: sql
1.
2.
DELETE FROM table
WHERE id NOT IN (SELECT max(id) FROM table GROUP BY name, surname)


определение оригинала, как записи с минимальным id - это ваше домысливание
тем не менее, в такой постановке заменяем max на min
...
Рейтинг: 0 / 0
17.01.2019, 06:00
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760600
niteshade
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
niteshade
Гость
Андрей ПанфиловniteshadeОн правильный.Нет, там еще фамилия же. Вообщем в лоб (без всяких group by, аналитических функций и пр):
Код: sql
1.
2.
3.
4.
5.
6.
7.
delete table t1
where exists (
 select * from table t2
 where t1.name=t2.name
 and t1.surname=t2.surname
 and t1.id > t2.id
)



PS. кто
есть типовой запрос:
Код: sql
1.
2.
DELETE FROM table
WHERE id NOT IN (SELECT max(id) FROM table GROUP BY name, surname)


он просто и эффективен
зачем переписывать его в более сложной и менее эффективной форме?
...
Рейтинг: 0 / 0
17.01.2019, 06:05
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760602
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
niteshadeесть типовой запрос:
Код: sql
1.
2.
DELETE FROM table
WHERE id NOT IN (SELECT max(id) FROM table GROUP BY name, surname)


он просто и эффективен
зачем переписывать его в более сложной и менее эффективной форме?

Ну для начала, попробуйте найти ошибку в "типовом" запросе - она там есть и довольно существенная. Во вторых с "эффективностью" там так себе:

Код: sql
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.
SQL> DELETE task1 t1
 WHERE id NOT IN (  SELECT MAX (id)
                      FROM task1 t2
                  GROUP BY name);  2    3    4


Execution Plan
----------------------------------------------------------
Plan hash value: 1998126981

-------------------------------------------------------------------------------------------
| Id  | Operation              | Name     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT       |          |  1000K|   133M|       | 32224   (1)| 00:00:02 |
|   1 |  DELETE                | TASK1    |       |       |       |            |          |
|*  2 |   HASH JOIN RIGHT ANTI |          |  1000K|   133M|    23M| 32224   (1)| 00:00:02 |
|   3 |    VIEW                | VW_NSO_1 |   989K|    12M|       | 19252   (1)| 00:00:01 |
|   4 |     SORT GROUP BY      |          |   989K|   119M|   130M| 19252   (1)| 00:00:01 |
|   5 |      INDEX FULL SCAN   | T1_X     |  1000K|   121M|       | 19252   (1)| 00:00:01 |
|   6 |    INDEX FAST FULL SCAN| T1_X     |  1000K|   121M|       |  5219   (1)| 00:00:01 |
-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ID"="MAX(ID)")


Statistics
----------------------------------------------------------
        135  recursive calls
        876  db block gets
      38625  consistent gets
      17248  physical reads
     333084  redo size
        867  bytes sent via SQL*Net to client
       1041  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          1  sorts (memory)
          1  sorts (disk)



Код: sql
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.
SQL> DELETE task1 t1
 WHERE EXISTS
          (SELECT *
             FROM task1 t2
            WHERE t1.name = t2.name AND t1.id > t2.id);  2    3    4    5


Execution Plan
----------------------------------------------------------
Plan hash value: 2072444764

----------------------------------------------------------------------------------------
| Id  | Operation              | Name  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT       |       |   506K|   122M|       | 23598   (1)| 00:00:01 |
|   1 |  DELETE                | TASK1 |       |       |       |            |          |
|*  2 |   HASH JOIN SEMI       |       |   506K|   122M|   132M| 23598   (1)| 00:00:01 |
|   3 |    INDEX FAST FULL SCAN| T1_X  |  1000K|   121M|       |  5219   (1)| 00:00:01 |
|   4 |    INDEX FAST FULL SCAN| T1_X  |  1000K|   121M|       |  5219   (1)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("T1"."NAME"="T2"."NAME")
       filter("T1"."ID">"T2"."ID")


Statistics
----------------------------------------------------------
          0  recursive calls
        805  db block gets
      38781  consistent gets
          0  physical reads
     315792  redo size
        867  bytes sent via SQL*Net to client
       1052  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
...
Рейтинг: 0 / 0
17.01.2019, 07:00
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760612
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
niteshade, он правильный только для данного набора данных, вроде уже обсудили.
...
Рейтинг: 0 / 0
17.01.2019, 08:24
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760629
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
Андрей Панфилов, а почему во втором случае 0 physical reads?
...
Рейтинг: 0 / 0
17.01.2019, 09:33
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760643
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
Озверин,

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
"Delete on names  (cost=1081.09..1747.03 rows=15198 width=6) (actual time=31.138..31.138 rows=0 loops=1)"
"  ->  Seq Scan on names  (cost=1081.09..1747.03 rows=15198 width=6) (actual time=26.771..30.621 rows=933 loops=1)"
"        Filter: (NOT (hashed SubPlan 1))"
"        Rows Removed by Filter: 15729"
"        SubPlan 1"
"          ->  HashAggregate  (cost=817.91..1028.45 rows=21054 width=40) (actual time=20.265..22.960 rows=15729 loops=1)"
"                ->  Seq Scan on names names_1  (cost=0.00..589.95 rows=30395 width=40) (actual time=0.004..9.098 rows=16662 loops=1)"
"Total runtime: 31.258 ms"


"Delete on names t1  (cost=681.22..3179.15 rows=5243 width=12) (actual time=38.338..38.338 rows=0 loops=1)"
"  ->  Hash Semi Join  (cost=681.22..3179.15 rows=5243 width=12) (actual time=38.337..38.337 rows=0 loops=1)"
"        Hash Cond: (((t1.f)::text = (t2.f)::text) AND ((t1.s)::text = (t2.s)::text))"
"        Join Filter: (t1.id > t2.id)"
"        Rows Removed by Join Filter: 15729"
"        ->  Seq Scan on names t1  (cost=0.00..445.29 rows=15729 width=46) (actual time=0.004..4.245 rows=15729 loops=1)"
"        ->  Hash  (cost=445.29..445.29 rows=15729 width=46) (actual time=20.473..20.473 rows=15729 loops=1)"
"              Buckets: 2048  Batches: 1  Memory Usage: 1227kB"
"              ->  Seq Scan on names t2  (cost=0.00..445.29 rows=15729 width=46) (actual time=0.002..7.740 rows=15729 loops=1)"
"Total runtime: 38.378 ms"



в моем случае разница не велика в пользу агрегирования(быстрее, чем джоины) на таблице в 15000 записей и при условии, что ни одна из них не будет удалена. В случае, если перейти на выборку по одному текстовому полю, а не по двум - результаты остаются очень похожими.
...
Рейтинг: 0 / 0
17.01.2019, 09:58
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760646
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
Озверин,


Код: sql
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.
-- Table: temp.names

-- DROP TABLE temp.names;

CREATE TABLE temp.names
(
  id integer NOT NULL,
  f character varying(150),
  s character varying(150),
  CONSTRAINT pk PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE temp.names
  OWNER TO postgres;

-- Index: temp.f_idx

-- DROP INDEX temp.f_idx;

CREATE INDEX f_idx
  ON temp.names
  USING btree
  (f COLLATE pg_catalog."default");

-- Index: temp.s_idx

-- DROP INDEX temp.s_idx;

CREATE INDEX s_idx
  ON temp.names
  USING btree
  (s COLLATE pg_catalog."default");

EXPLAIN ANALYZE DELETE FROM temp.names
WHERE id NOT IN (SELECT max(id) FROM temp.names GROUP BY f)

EXPLAIN ANALYZE  DELETE FROM temp.names t1
 WHERE EXISTS
          (SELECT t2.*
             FROM temp.names t2
            WHERE t1.f = t2.f AND t1.id > t2.id);
...
Рейтинг: 0 / 0
17.01.2019, 09:59
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760647
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
Озверин,

и вариант со сравнением по 2м полям:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
EXPLAIN ANALYZE DELETE FROM temp.names
WHERE id NOT IN (SELECT max(id) FROM temp.names GROUP BY f, s)

EXPLAIN ANALYZE  DELETE FROM temp.names t1
 WHERE EXISTS
          (SELECT t2.*
             FROM temp.names t2
            WHERE t1.f = t2.f AND t1.s = t2.s AND t1.id > t2.id);
...
Рейтинг: 0 / 0
17.01.2019, 10:00
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760653
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
Озверин,

и наконец, корректный вариант дает очень схожу картину мира:

EXPLAIN ANALYZE
DELETE
FROM temp.names t1
WHERE t1.id NOT IN(SELECT min(t2.id) FROM temp.names t2 GROUP BY t2.f, t2.s HAVING count(t2.id)>1 OR count(t2.id)=1);


"Delete on names t1 (cost=742.56..1127.83 rows=8331 width=6) (actual time=35.358..35.358 rows=0 loops=1)"
" -> Seq Scan on names t1 (cost=742.56..1127.83 rows=8331 width=6) (actual time=35.357..35.357 rows=0 loops=1)"
" Filter: (NOT (hashed SubPlan 1))"
" Rows Removed by Filter: 15729"
" SubPlan 1"
" -> HashAggregate (cost=551.89..715.32 rows=10895 width=40) (actual time=23.995..28.049 rows=15729 loops=1)"
" Filter: ((count(t2.id) > 1) OR (count(t2.id) = 1))"
" -> Seq Scan on names t2 (cost=0.00..343.62 rows=16662 width=40) (actual time=0.007..6.850 rows=15729 loops=1)"
"Total runtime: 35.475 ms"

Все это связано с тем, что после 1-2х запросов большинство баз создает свой какой-нить хэш-агрегат и уже работает с ним. Потому, чтобы показать РЕАЛЬНУЮ разницу между по сути очень похожими запросами, надо поработать с базой, поудалять оттуда данные, повставлять новые, повыполнять запросы на удаление, а потом уже анализировать итоги. Как и в java - надо бе разогреться.
...
Рейтинг: 0 / 0
17.01.2019, 10:09
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760657
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
Озверина почему во втором случае 0 physical reads?Потому что табличка с индексом в память легла - оракл может себе позволить, а вопрос скорее всего в том, почему в первом случае (group by) не 0, ответ тут простой: оно сортировку решило не в памяти делать, а на диске (1 sorts (disk)). В случае ваших 15 тыс. смотреть даже нечего, сделайте несколько миллионов и индекс нормальный, типа (дубликат, id).

Ну и еще доводы в пользу exists:
в случае group by возникают краевые эффекты на пустых полях: в данном случае "получится" что null=null, т.е. группируем налы, а удаляем уже по id

из-за NOT IN возникают краевые эффекты на пустых id, т.е. если в таблице есть пустой id, то запрос вообще ничего не удалит

в случае exists я могу базу бомбить несколькими запросами одновременно, просто добавив во внешнее условие name like 'A%', name like 'B%' и пр. В случае group by условие нужно добавлять уже в два места чтобы они коррелировали
...
Рейтинг: 0 / 0
17.01.2019, 10:16
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760700
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
Андрей Панфилов, так если сделать 15 млн, то и не ляжет вся она в память, а только - частично. О том и разговор, что первый запрос при всей неэффективности отработал всего на 1 секунду медленее, но НА ДИСКЕ. Короче, на неразогретом оракле. В моем случае он отработал быстрее в обоих случаях.

1. это специфичное для оракла? В пг группировка по null - всегда отдельная группа и никакого сравнения просто нет.
2. пустой primary key? это уже эффект какой-то подозрительный.
3.при like уже под большим вопросом вообще использование индексов, так что делать то вы можете что угодно, но как это повлияет на план запроса - вы не знаете. Правда я вообще не понял, про что этот пункт.
...
Рейтинг: 0 / 0
17.01.2019, 11:10
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760702
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
Озверин, единственное, что, для PG - not in менее эффективен в плане работы, чем exists. Потому можно на него перейти, проверить.
...
Рейтинг: 0 / 0
17.01.2019, 11:13
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760733
niteshade
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
niteshade
Гость
Андрей Панфиловniteshadeесть типовой запрос:
Код: sql
1.
2.
DELETE FROM table
WHERE id NOT IN (SELECT max(id) FROM table GROUP BY name, surname)


он просто и эффективен
зачем переписывать его в более сложной и менее эффективной форме?

Ну для начала, попробуйте найти ошибку в "типовом" запросе - она там есть и довольно существенная. Во вторых с "эффективностью" там так себе:

Код: sql
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.
SQL> DELETE task1 t1
 WHERE id NOT IN (  SELECT MAX (id)
                      FROM task1 t2
                  GROUP BY name);  2    3    4


Execution Plan
----------------------------------------------------------
Plan hash value: 1998126981

-------------------------------------------------------------------------------------------
| Id  | Operation              | Name     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT       |          |  1000K|   133M|       | 32224   (1)| 00:00:02 |
|   1 |  DELETE                | TASK1    |       |       |       |            |          |
|*  2 |   HASH JOIN RIGHT ANTI |          |  1000K|   133M|    23M| 32224   (1)| 00:00:02 |
|   3 |    VIEW                | VW_NSO_1 |   989K|    12M|       | 19252   (1)| 00:00:01 |
|   4 |     SORT GROUP BY      |          |   989K|   119M|   130M| 19252   (1)| 00:00:01 |
|   5 |      INDEX FULL SCAN   | T1_X     |  1000K|   121M|       | 19252   (1)| 00:00:01 |
|   6 |    INDEX FAST FULL SCAN| T1_X     |  1000K|   121M|       |  5219   (1)| 00:00:01 |
-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ID"="MAX(ID)")


Statistics
----------------------------------------------------------
        135  recursive calls
        876  db block gets
      38625  consistent gets
      17248  physical reads
     333084  redo size
        867  bytes sent via SQL*Net to client
       1041  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          1  sorts (memory)
          1  sorts (disk)



Код: sql
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.
SQL> DELETE task1 t1
 WHERE EXISTS
          (SELECT *
             FROM task1 t2
            WHERE t1.name = t2.name AND t1.id > t2.id);  2    3    4    5


Execution Plan
----------------------------------------------------------
Plan hash value: 2072444764

----------------------------------------------------------------------------------------
| Id  | Operation              | Name  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT       |       |   506K|   122M|       | 23598   (1)| 00:00:01 |
|   1 |  DELETE                | TASK1 |       |       |       |            |          |
|*  2 |   HASH JOIN SEMI       |       |   506K|   122M|   132M| 23598   (1)| 00:00:01 |
|   3 |    INDEX FAST FULL SCAN| T1_X  |  1000K|   121M|       |  5219   (1)| 00:00:01 |
|   4 |    INDEX FAST FULL SCAN| T1_X  |  1000K|   121M|       |  5219   (1)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("T1"."NAME"="T2"."NAME")
       filter("T1"."ID">"T2"."ID")


Statistics
----------------------------------------------------------
          0  recursive calls
        805  db block gets
      38781  consistent gets
          0  physical reads
     315792  redo size
        867  bytes sent via SQL*Net to client
       1052  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)


индексы откуда появились?
опять домысливания?
...
Рейтинг: 0 / 0
17.01.2019, 11:53
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760741
niteshade
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
niteshade
Гость
Для Oracle всё ещё проще:
Код: sql
1.
2.
DELETE FROM table
WHERE not rowid IN (SELECT max(rowid) FROM table GROUP BY name, surname)
...
Рейтинг: 0 / 0
17.01.2019, 11:59
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760742
chpasha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chpasha
Участник
Озвериндля PG
для PG кстати работает еще такой запрос (не знаю, пробегал ли - не читал топик целиком)
Код: sql
1.
2.
3.
4.
DELETE   FROM table_with_dups T1
  USING       table_with_dups T2
WHERE  T1.ctid    < T2.ctid     
  AND  T1.name    = T2.name
...
Рейтинг: 0 / 0
17.01.2019, 11:59
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760743
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
niteshadeиндексы откуда появились?
опять домысливания?

не откуда, а какие - полнотекстовые какие-нибудь.
...
Рейтинг: 0 / 0
17.01.2019, 11:59
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760752
niteshade
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
niteshade
Гость
Озверин,
это уже какая-то яростная дичь)
в первом сообщении топика есть условия
исходя из них необходимо решить задачу
может, хватит уже натягивать сову на глобус?))
...
Рейтинг: 0 / 0
17.01.2019, 12:12
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760756
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
chpashaОзвериндля PG
для PG кстати работает еще такой запрос (не знаю, пробегал ли - не читал топик целиком)
Код: sql
1.
2.
3.
4.
DELETE   FROM table_with_dups T1
  USING       table_with_dups T2
WHERE  T1.ctid    < T2.ctid     
  AND  T1.name    = T2.name



я как-то с сомнением, если развернуть запрос похоже на :

Код: sql
1.
2.
DELETE FROM table_with_dups T1
WHERE T1.ctid IN(SELECT T2.ctid FROM table_with_dups T2 WHERE  T1.ctid < T2.ctid AND T1.name = T2.name)



то есть похоже, что он сделает ровно обратное. Я не прав?

p.s. в данном случае USING -специфичен для базы.
...
Рейтинг: 0 / 0
17.01.2019, 12:17
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760758
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
niteshadeОзверин,
это уже какая-то яростная дичь)
в первом сообщении топика есть условия
исходя из них необходимо решить задачу
может, хватит уже натягивать сову на глобус?))

вопрос пошел немного дальше. Правильные запросы уже были. Что вам не нравится? Не хотите - не обсуждайте.
...
Рейтинг: 0 / 0
17.01.2019, 12:18
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760760
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
Озверинchpashaпропущено...

для PG кстати работает еще такой запрос (не знаю, пробегал ли - не читал топик целиком)
Код: sql
1.
2.
3.
4.
DELETE   FROM table_with_dups T1
  USING       table_with_dups T2
WHERE  T1.ctid    < T2.ctid     
  AND  T1.name    = T2.name



я как-то с сомнением, если развернуть запрос похоже на :

Код: sql
1.
2.
DELETE FROM table_with_dups T1
WHERE T1.ctid IN(SELECT T2.ctid FROM table_with_dups T2 WHERE  T1.ctid < T2.ctid AND T1.name = T2.name)



то есть похоже, что он сделает ровно обратное. Я не прав?

p.s. в данном случае USING -специфичен для базы.

а не, вроде все ок.
...
Рейтинг: 0 / 0
17.01.2019, 12:22
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760919
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Execution plan будем смотреть?

Потому-что для некоторых dbms существует т.н. аналитические функции которые тоже
позволяют решать данную задачу.

Вообще - удаление дубликатов - это страшный боян и в профильных топиках уже на это
не отвечают а просто кидают тебя в Stackoverflow или в какой-то ФАК.

И зачем мы это мурыжым?
...
Рейтинг: 0 / 0
17.01.2019, 14:57
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39760940
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
Я ждал выступления начальника транспортного цеха и вади...
...
Рейтинг: 0 / 0
17.01.2019, 15:14
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39761015
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
Озверинтак если сделать 15 млн, то и не ляжет вся она в память, а только - частично.Ну а какая разница-то? С group by появляется дополнительная операция, как ни крути, она чего-то да и стоит, а изначальный пойнт был в том, что exists - ну это вообще супер сложно и неэффективно, пока автору сего утверждения правоту доказать не удалось.

Озверин1. это специфичное для оракла? В пг группировка по null - всегда отдельная группа и никакого сравнения просто нетну вот есть таблица

idname1null2null
в результате group by с max(id) она превратится в:

idname2null
в итоге delete удалит первую запись, вопрос: это ожидаемое поведение с т.з. постановки задачи или нет? Т.е. когда мы говорим про дубликаты, null = null или нет (когда мы в контексте СУБД, то там все null разные)?

Озверин2. пустой primary key? это уже эффект какой-то подозрительный.ну это вы по названию колонки домыслили уже, а без DDL таблицы что там в действительности - неизвестно.

Озверин3.при like уже под большим вопросом вообще использование индексов, так что делать то вы можете что угодно, но как это повлияет на план запроса - вы не знаете. Правда я вообще не понял, про что этот пункт.ну вот у вас есть PostgreSQL, который не умеет parallel а в базе триллион записей, вопрос: как ускорить удаление?

В целом же, любая логика, основанная на отрицании - она априори неправильная, потому что заставляет думать в четыре раза больше, так что если можно писать прямо, то нужно так и делать.
...
Рейтинг: 0 / 0
17.01.2019, 16:09
| Ответить | Цитировать | Написать  
Вопросы на собеседовании
    #39761065
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
Андрей Панфилов,

0. Изначальный поинт был про сложно воспринимаемый (человеком для быстрого осмысления) запрос, где много джоинов по текстовым полям. Не знаю, причем тут exist.
1. это странно считать, что за счет доп операции алгоритм будет менее эффективным. Если бы запросы были абсолютно идентичными и в один из них мы вставили доп операцию - это высказывание хотя бы логику имело.
2. Я не знаю, являются ли для постановщика задачи null равными между собой или нет. Спросите у постановщика.
3. Если домысливать нельзя, то изначально дискуссия не имеет смысла и подходит любой запрос для 5 строк. Если бы нельзя было "домысливать", то зачем вы сделали индексы для таблицы, а потом по ним план запроса построили?
4. Если у меня будет триллион записей и этот запрос не будет справляться, я буду смотреть какой запрос лучше справиться с триллионом записей, как я буду смотреть, какой запрос лучше справиться с миллионом записей.
...
Рейтинг: 0 / 0
17.01.2019, 17:33
| Ответить | Цитировать | Написать  
24 сообщений из 149, страница 6 из 6
  6  все
Форумы / Java [игнор отключен] [закрыт для гостей] / Вопросы на собеседовании
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&msg=39760646&tid=2121531]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 152ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 62ms
get tp. blocked users:
 1ms
others: 350ms
total:  605ms
созд. / загр.: 605ms
x
x
Закрыть


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