tail -qn +2 files/*.txt > data.csvdir / ls) и, допустим, в продвинутом текстовом редакторе дописываете к каждому названию куски команды COPY. Получится один большой скрипт SELECT rownum FROM (SELECT row_number() over(ORDER BY rate DESC) rownum, id FROM users) q WHERE id = ?возвращать одно рандомное из дублей, но тогда есть вероятность вывода неправильного результата
SELECT DISTINCT ON (project_id) *
FROM tasks
WHERE tasks.id = ANY (...)
ORDER BY project_id, createdБудет ли от этого оптимизация или будет еще хуже?
> EXPLAIN ANALYZE select count(*) from u where val like 'xz%';
-> Aggregate: count(0) (actual time=358.829..358.829 rows=1 loops=1)
-> Filter: (u.val like 'xz%') (cost=1081.88 rows=4995) (actual time=0.388..358.196 rows=4995 loops=1)
-> Index range scan on u using u_val (cost=1081.88 rows=4995) (actual time=0.383..356.709 rows=4995 loops=1)
> EXPLAIN ANALYZE select count(*) from (select id from u where val like 'zx%' limit 11) q;
-> Aggregate: count(0) (actual time=1.609..1.609 rows=1 loops=1)
-> Table scan on q (actual time=0.002..0.005 rows=11 loops=1)
-> Materialize (actual time=1.594..1.601 rows=11 loops=1)
-> Limit: 11 row(s) (actual time=0.089..1.560 rows=11 loops=1)
-> Filter: (u.val like 'zx%') (cost=1183.58 rows=5465) (actual time=0.088..1.555 rows=11 loops=1)
-> Index range scan on u using u_val (cost=1183.58 rows=5465) (actual time=0.082..1.537 rows=11 loops=1)with recursive q as (
select * from tes where from_id = 1
union all
select tes.* from tes, q where tes.from_id = q.to_id
)
select * from q order by from_id, to_idonly_full_group_by из sql_mode rows в выводе EXPLAIN по определению неточные - это оценка, исходя из статистики.group_concat(case when status <> 0 then status end)__and__ эмулирует побитовую конъюнкцию (побитовый AND), которая в питоне делается так:a & b m.start().re.finditer():[m.start() for m in re.finditer("\d", s1)]idxs = []
l = 0
while m := re.search("\d", s1):
idxs.append(l + m.start())
l += m.end()
s1 = s1[m.end():][i for i, c in enumerate(s1) if c >= '0' and c <= '9']если оставить всё, как есть, то primary key будет обновляться при каждой вставкене ключ, а внутренний объект (аналог sequence в других СУБД)
из-за чего, во-первых, он когда-то закончитсячто, прям так много вставок? сделайте поле BIGINT
таблица постоянно будет переиндексироваться (старая с маленьким ключом запись при обновлении будет "подниматься" наверх)вообще не понял, что это значит
как умные люди решают вопрос уникального кортежа в такой таблице?в описанном случае не вижу никаких проблем использовать
insert ... on duplicate key update class A:
def __init__(self, value):
print("A::__init__")
self.value = value
class B:
def __init__(self, name):
print("B::__init__")
self.name = name
class C(A, B):
def __init__(self, name, value):
super().__init__(value)
super(A, self).__init__(name)
print(C.__mro__)
t = C('Name', 0)super(Class, obj).method() ищется метод родительского класса, правее Class по цепочке mro:(<class '__main__.C'>, <class '__main__.A'>, <class '__main__.B'>, <class 'object'>)super() - в данном случае равносильно super(C, self) - поиск начнется с A \d+ myTable в psql для интереса), так что если вы не указываете значение для id в INSERT, оно берется из сиквенса.INSERT INTO myTable(lastName) VALUES('upsertedLastNameOnly orger') ON CONFLICT (id)