Телеграмм чат группы pgsql страница 10635

19:18пожаловаться #1

YS

Yaroslav Schekin in pgsql – PostgreSQL

ram 8
cpu 2
disk HDD
num disk 1
size DB 1TB (actually 400gb)
workload: purely analytical and large aggregation
reading tr: 80%
connections: 40
replica 0

Понятно, спасибо.
Несколько отвлекаясь от темы — Вам не кажется, что (если это всё "горячие" данные) RAM у Вас маловато для базы такого размера?

19:19пожаловаться #2

K

нет, это не горячие данные.

19:19пожаловаться #3

K

пока это можно назвать тестовым стендом.

19:20пожаловаться #4

K

этf бд из 2-х таблиц занимает 65 gb

19:21пожаловаться #5

K

но "влить" в нее в последствии планируется ~ 400gb

19:22пожаловаться #6

YS

Yaroslav Schekin in pgsql – PostgreSQL

этf бд из 2-х таблиц занимает 65 gb

И даже так — это "замечательный" cache hit где-то в 3%. :(
А cache miss "уходят" в HDD, что (особенно, с random reads) очень "больно", какой производительности тут можно хотеть в подобных запросах?

19:25пожаловаться #7

YS

Yaroslav Schekin in pgsql – PostgreSQL

пока это можно назвать тестовым стендом.

Ну ладно, а если создать покрывающие индексы прямо под этот запрос (хотя бы лучшее, чего тут можно добиться, увидим)?

19:27пожаловаться #8

K

Yaroslav Schekin

И даже так — это "замечательный" cache hit где-то в 3%. :(
А cache miss "уходят" в HDD, что (особенно, с random reads) очень "больно", какой производительности тут можно хотеть в подобных запросах?

Хорошо, значит ли это дальнейшие попытки оптимизации подобных запросов будут лишены смысла пока «железо» не подкинуть?!

19:28пожаловаться #9

K

Yaroslav Schekin

Ну ладно, а если создать покрывающие индексы прямо под этот запрос (хотя бы лучшее, чего тут можно добиться, увидим)?

Сейчас почитаю про покрывающие индексы и попробую сделать.

19:31пожаловаться #10

YS

Yaroslav Schekin in pgsql – PostgreSQL

Хорошо, значит ли это дальнейшие попытки оптимизации подобных запросов будут лишены смысла пока «железо» не подкинуть?!

По крайне мере, вот даже в этом запросе с диска читается примерно 22 GB, и занимает это 149 секунд:

->  Seq Scan on csco_ifndq i  (cost=0.00..6301036.60 rows=336696160 width=30) (actual time=0.510..149002.725 rows=336723160 loops=1)
      Buffers: shared hit=64 read=2934011

Для HDD — это нормальная скорость, вполне возможно. Куда Вы это время денете, если индексов не создавать (а они тоже имеют свою "цену" в плане использования диска и снижения производительности обновлений)?
Т.е. с таким железом остаётся как-то сделать так, чтобы приходилось меньше читать — для этого покрывающие индексы.
Т.е. такие, которые подходят как для выборки (под условия), так и содержат все данные, которые будет выдавать SELECT.

19:34пожаловаться #11

K

Yaroslav Schekin

По крайне мере, вот даже в этом запросе с диска читается примерно 22 GB, и занимает это 149 секунд:

->  Seq Scan on csco_ifndq i  (cost=0.00..6301036.60 rows=336696160 width=30) (actual time=0.510..149002.725 rows=336723160 loops=1)
      Buffers: shared hit=64 read=2934011

Для HDD — это нормальная скорость, вполне возможно. Куда Вы это время денете, если индексов не создавать (а они тоже имеют свою "цену" в плане использования диска и снижения производительности обновлений)?
Т.е. с таким железом остаётся как-то сделать так, чтобы приходилось меньше читать — для этого покрывающие индексы.
Т.е. такие, которые подходят как для выборки (под условия), так и содержат все данные, которые будет выдавать SELECT.

Спасибо за разъяснение. Да и чтение explain становится более осмысленным!

19:37пожаловаться #12

YS

Yaroslav Schekin in pgsql – PostgreSQL

Сейчас почитаю про покрывающие индексы и попробую сделать.

Т.е. запрос был такой?

SELECT k.gvkey, k.datadate, i.valuei, i.item, i.effdate, i.thrudate, k.datafmt
  FROM csco_ifndq AS i
  JOIN csco_idesind_2008_2020 AS k 
    ON k.coifnd_id = i.coifnd_id
 WHERE k.gvkey IN (...500)
   AND k.datadate BETWEEN '2013-10-01 00:00:00' AND '2015-09-01 00:00:00'

Тогда покрывающие индексы под него какие-то такие, на первый взгляд:

CREATE INDEX ON csco_idesind_2008_2020(datadate, gvkey) INCLUDE (datafmt);
CREATE INDEX ON csco_ifndq(coifnd_id) INCLUDE (valuei, item, effdate, thrudate);

Но это, скорее, для эксперимента (и места они займут тоже прилично, по идее).

19:40пожаловаться #13

K

Yaroslav Schekin

Т.е. запрос был такой?

SELECT k.gvkey, k.datadate, i.valuei, i.item, i.effdate, i.thrudate, k.datafmt
  FROM csco_ifndq AS i
  JOIN csco_idesind_2008_2020 AS k 
    ON k.coifnd_id = i.coifnd_id
 WHERE k.gvkey IN (...500)
   AND k.datadate BETWEEN '2013-10-01 00:00:00' AND '2015-09-01 00:00:00'

Тогда покрывающие индексы под него какие-то такие, на первый взгляд:

CREATE INDEX ON csco_idesind_2008_2020(datadate, gvkey) INCLUDE (datafmt);
CREATE INDEX ON csco_ifndq(coifnd_id) INCLUDE (valuei, item, effdate, thrudate);

Но это, скорее, для эксперимента (и места они займут тоже прилично, по идее).

Да, такой. Да, ща проверю )

19:42пожаловаться #14

YS

Yaroslav Schekin in pgsql – PostgreSQL

Да, такой. Да, ща проверю )

А, стоп, забыл coifnd_id в индексе для csco_idesind_2008_2020. ;)

CREATE INDEX ON csco_idesind_2008_2020(datadate, gvkey) INCLUDE (datafmt, coifnd_id);

19:46пожаловаться #15

K

👌

19:47пожаловаться #16

B

BAHR in pgsql – PostgreSQL

Привет! У меня тут дурацкий вопрос. Можно ли средствами бд ограничить размер таблицы??? То есть у нас есть таблица, которую мы по тихоньку заполняем данными, но при этом когда данных становится больше 1000 строк, что-бы при внесении следующей строки автоматом удалилась самая первая??? Ткните пожалуйста в какую сторону капать:)

19:50пожаловаться #17

D

Denis in pgsql – PostgreSQL

BAHR

Привет! У меня тут дурацкий вопрос. Можно ли средствами бд ограничить размер таблицы??? То есть у нас есть таблица, которую мы по тихоньку заполняем данными, но при этом когда данных становится больше 1000 строк, что-бы при внесении следующей строки автоматом удалилась самая первая??? Ткните пожалуйста в какую сторону капать:)

триггер написать

Сергей Голод... in pgsql – PostgreSQL

19:50пожаловаться #18

СГ

BAHR

Привет! У меня тут дурацкий вопрос. Можно ли средствами бд ограничить размер таблицы??? То есть у нас есть таблица, которую мы по тихоньку заполняем данными, но при этом когда данных становится больше 1000 строк, что-бы при внесении следующей строки автоматом удалилась самая первая??? Ткните пожалуйста в какую сторону капать:)

в сторону определения "самая первая"

19:51пожаловаться #19

K

Yaroslav Schekin

Т.е. запрос был такой?

SELECT k.gvkey, k.datadate, i.valuei, i.item, i.effdate, i.thrudate, k.datafmt
  FROM csco_ifndq AS i
  JOIN csco_idesind_2008_2020 AS k 
    ON k.coifnd_id = i.coifnd_id
 WHERE k.gvkey IN (...500)
   AND k.datadate BETWEEN '2013-10-01 00:00:00' AND '2015-09-01 00:00:00'

Тогда покрывающие индексы под него какие-то такие, на первый взгляд:

CREATE INDEX ON csco_idesind_2008_2020(datadate, gvkey) INCLUDE (datafmt);
CREATE INDEX ON csco_ifndq(coifnd_id) INCLUDE (valuei, item, effdate, thrudate);

Но это, скорее, для эксперимента (и места они займут тоже прилично, по идее).

если железа выделят побольше, партиционность таблиц поможет? тк сейчас в качестве эксперимента csco_idesind_2008_2020 это кусок csco_idesind, а там данные с 1993 года, если с ней начать работы...