Postgres считать или сумма, игнорируя грязные вещи

Question

Postgres считать или сумма, игнорируя грязные вещи

0

У меня есть индекс, где информация, которую нужно суммировать, указана в индексе. Индекс выглядит как (key,sumable_attribute).

Теперь, если я скажу:

SELECT sum(sumable_attribute) from table where key between 1 and 1000000

Было бы идеально, если бы мы могли бегать вдоль связанных листьев b-дерева и собирать sumable_attributes.

НО: MVCC сообщает нам проверить видимость данных... Мне все равно, если мой результат не на 100% правильный, если он работает быстро. MyISAM быстро...

Как сообщить postgres игнорировать это?

Franz Kafka 09 март 2011, в 16:48

Источник

3

Если вас не волнует точность данных, поступающих из вашей базы данных, вам, вероятно, следует отойти от клавиатуры, пока вы не сделаете
Adam Batkin 09 март 2011, в 15:14
0

Я также не вижу, что MVCC имеет отношение к этому
Adam Batkin 09 март 2011, в 15:30
1

Что делать, если у всех сегодня проблемы? Представьте, что у вас есть банк, и вас интересует, сколько наличных денег доступно для принятия быстрого решения. Вы не можете сказать мне, что вам небезразлично, если кто-то получит 10 долларов от банкомата. Готовые грязные данные очень часто встречаются в базах данных, поэтому, пожалуйста, не говорите мне, что это неправильно. В нужном контексте не имеет значения, если результат равен 0,01%.
Franz Kafka 09 март 2011, в 15:34
0

@Adam MVCC заставляет посетить таблицу, чтобы проверить, видны ли данные. Без посещения таблицы информация может быть непосредственно взята с листьев индекса. Нет случайного ввода-вывода на диске. Делает вещи так намного быстрее. Для этого варианта использования очень хороший компромисс
Franz Kafka 09 март 2011, в 15:35
1

Попробуйте перефразировать вопрос с точки зрения того, что вы на самом деле хотите. Например: «Я хочу выполнить этот запрос, но он слишком медленный. Вот мой индекс. Что я могу сделать?»
Adam Batkin 09 март 2011, в 15:39
1

Это не является прямым следствием MVCC, но является следствием того факта, что индексные блоки в Postgres не несут информацию MVCC. Поэтому проверка в таблице необходима. Oracle и другие, которые также реализуют MVCC, имеют информацию о видимости в индексе и, таким образом, могут полностью удовлетворить запрос из индекса. В настоящее время есть планы реализовать это и для Postgres, но это будущий разговор (этого не произойдет для 9.1)
a_horse_with_no_name 09 март 2011, в 16:31

Показать ещё 4 комментария

Теги:

mysql

database

sql

postgresql

sum

1 ответ

Ещё вопросы

Если вас не волнует точность данных, поступающих из вашей базы данных, вам, вероятно, следует отойти от клавиатуры, пока вы не сделаете
Я также не вижу, что MVCC имеет отношение к этому
Что делать, если у всех сегодня проблемы? Представьте, что у вас есть банк, и вас интересует, сколько наличных денег доступно для принятия быстрого решения. Вы не можете сказать мне, что вам небезразлично, если кто-то получит 10 долларов от банкомата. Готовые грязные данные очень часто встречаются в базах данных, поэтому, пожалуйста, не говорите мне, что это неправильно. В нужном контексте не имеет значения, если результат равен 0,01%.
@Adam MVCC заставляет посетить таблицу, чтобы проверить, видны ли данные. Без посещения таблицы информация может быть непосредственно взята с листьев индекса. Нет случайного ввода-вывода на диске. Делает вещи так намного быстрее. Для этого варианта использования очень хороший компромисс
Попробуйте перефразировать вопрос с точки зрения того, что вы на самом деле хотите. Например: «Я хочу выполнить этот запрос, но он слишком медленный. Вот мой индекс. Что я могу сделать?»
Это не является прямым следствием MVCC, но является следствием того факта, что индексные блоки в Postgres не несут информацию MVCC. Поэтому проверка в таблице необходима. Oracle и другие, которые также реализуют MVCC, имеют информацию о видимости в индексе и, таким образом, могут полностью удовлетворить запрос из индекса. В настоящее время есть планы реализовать это и для Postgres, но это будущий разговор (этого не произойдет для 9.1)

Mike Sherrill 'Cat Recall' · Accepted Answer · 2011-03-09T12-56-00.000Z

1

Лучший ответ

PostgreSQL в настоящее время реализует два разных уровня изоляции: "Чтение совершенных" и "Сериализуемое". Вы можете запросить грязное чтение с помощью READ UNCOMMITTED, но вместо этого вы получите уровень изоляции "Read Committed".

Так как READ COMMITTED по умолчанию, вы, вероятно, используете самый быстрый уровень изоляции PostgreSQL.

Но публикация вывода EXPLAIN ANALYZE query_name_or_sql_statement может дать нам некоторые идеи.

Mike Sherrill 'Cat Recall' 09 март 2011, в 12:56

0

Хорошо, это было еще более теоретически, потому что я все еще решаю, какую систему базы данных использовать. Но это недостаток мэра. Нет возможности работы? Это означает, что я должен использовать кубы, чтобы поддерживать приемлемую производительность, это просто то, что я не хотел делать ... :-(
Franz Kafka 09 март 2011, в 16:12
0

Единственный обходной путь, который я могу придумать, - создать таблицу для суммы и написать триггер, чтобы поддерживать ее в актуальном состоянии. (И, может быть, напишите другую процедуру, которая запускается 'n' раз в день, чтобы убедиться, что сохраненная сумма и вычисленная сумма синхронизированы.) На вашем месте я бы собрал, загрузил и протестировал. В настоящее время каждый предлагает бесплатную версию своей СУБД. И я не раз был приятно удивлен фактическим исполнением.
Mike Sherrill 'Cat Recall' 09 март 2011, в 16:27
0

Другой подход в PostgreSQL может заключаться в использовании частичных индексов. Не знаю, относится ли это к вашему случаю.
Mike Sherrill 'Cat Recall' 09 март 2011, в 16:30
0

Другая идея: поместить индекс в табличное пространство на твердотельном диске. Или, может быть, положить таблицу и индекс на SSD.
Mike Sherrill 'Cat Recall' 09 март 2011, в 16:33

Показать ещё 2 комментария