Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
( http://developer.postgresql.org/pgdocs/postgres/release-8-2.html PS. count(*) так и не научили индексы использовать :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2006, 14:20 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Master AlexPS. count(*) так и не научили индексы использовать :( А я никогда count(*) на всю (большую) таблицу и не использовал. А если указываешь вменяемые условия, индексы все равно задействуются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2006, 16:01 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
А вот мне интересно - как можно заставить выдавать count - по таблице используя только индексы? В условиях архитектуры MVCC? Вот парни- те кому это кровь из носа как надо - распишите по простому -КАК? При этом учтите , что информация о версии записи в индексе не храниться. Т.е. узел индекса может ссылаться на уже удаленную запись - и узнать что она удалена можно только если сходить и посмотреть непосредственно на запись. В этом случае, если считать count по колличеству ключей в индексе- легко получить неправильный результат. Кстати по слухам SQL2005 - тоже теперь использует архитектуру MVCC(в простонаречии версионная архитектура). И по моему там count - также теперь считается перебором. ( Поправьте если я не прав...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2006, 16:52 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Master AlexPS. count(*) так и не научили индексы использовать :( А как ты будешь count(*) по индексам делать? Перебирать весь индекс и считать количество элементов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2006, 18:02 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
А что такое Warm standby server enhancements? Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2006, 00:14 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун А что такое Warm standby server enhancements? Насколько я понял, это бэкап-сервер, который получает wal-сегменты от боевого сервера и накатывает их у себя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2006, 08:29 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
domanixА вот мне интересно - как можно заставить выдавать count - по таблице используя только индексы? В условиях архитектуры MVCC? Я не спорю, что всегда можно использовать первичный индекс, но когда нет других активных транзакций, может можно из первичного индекса получить кол-во елементов? Не бейте сильно, если заблуждаюсь. Кстати по слухам SQL2005 - тоже теперь использует архитектуру MVCC(в простонаречии версионная архитектура). И по моему там count - также теперь считается перебором. ( Поправьте если я не прав...) Нет там первичный индекс используется, как и в Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2006, 13:45 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Кувалдин РоманА как ты будешь count(*) по индексам делать? Перебирать весь индекс и считать количество элементов? Еще год назад были следующие идеи : I think our TODO has a good summary of the issues: --------------------------------------------------------------------------- * Speed up COUNT(*) We could use a fixed row count and a +/- count to follow MVCC visibility rules, or a single cached value could be used and invalidated if anyone modifies the table. Another idea is to get a count directly from a unique index, but for this to be faster than a sequential scan it must avoid access to the heap to obtain tuple visibility information. * Add estimated_count(*) to return an estimate of COUNT(*) This would use the planner ANALYZE statistics to return an estimated count. * Allow data to be pulled directly from indexes Currently indexes do not have enough tuple visibility information to allow data to be pulled from the index without also accessing the heap. One way to allow this is to set a bit on index tuples to indicate if a tuple is currently visible to all transactions when the first valid heap lookup happens. This bit would have to be cleared when a heap tuple is expired. Another idea is to maintain a bitmap of heap pages where all rows are visible to all backends, and allow index lookups to reference that bitmap to avoid heap lookups, perhaps the same bitmap we might add someday to determine which heap pages need vacuuming. Frequently accessed bitmaps would have to be stored in shared memory. One 8k page of bitmaps could track 512MB of heap pages. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2006, 14:51 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
domanixКстати по слухам SQL2005 - тоже теперь использует архитектуру MVCC(в простонаречии версионная архитектура). И по моему там count - также теперь считается перебором. ( Поправьте если я не прав...) Вот план запроса select count(*) from emails MSSQL 2005 Express Edition c количеством записей 5 млн. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2006, 14:55 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Master AlexВот план запроса select count(*) from emails MSSQL 2005 Express Edition c количеством записей 5 млн.Налицо реализация пункта "Allow data to be pulled directly from indexes". Так же имхо работает и оракл. А вот mysql, снова имхо, действует по пункту "Speed up COUNT(*)". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2006, 15:12 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
domanixА вот мне интересно - как можно заставить выдавать count - по таблице используя только индексы? В условиях архитектуры MVCC? Вот парни- те кому это кровь из носа как надо - распишите по простому -КАК? При этом учтите , что информация о версии записи в индексе не храниться. Т.е. узел индекса может ссылаться на уже удаленную запись - и узнать что она удалена можно только если сходить и посмотреть непосредственно на запись. В этом случае, если считать count по колличеству ключей в индексе- легко получить неправильный результат. А каким образом стали работать MIN() и MAX() используя первичный индекс в условиях архитектуры MVCC???? Чем принципиально MIN() и MAX() отличаются от COUNT() по алгоритму прохода всех записей? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2006, 18:26 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Master Alex domanixА вот мне интересно - как можно заставить выдавать count - по таблице используя только индексы? В условиях архитектуры MVCC? Вот парни- те кому это кровь из носа как надо - распишите по простому -КАК? При этом учтите , что информация о версии записи в индексе не храниться. Т.е. узел индекса может ссылаться на уже удаленную запись - и узнать что она удалена можно только если сходить и посмотреть непосредственно на запись. В этом случае, если считать count по колличеству ключей в индексе- легко получить неправильный результат. А каким образом стали работать MIN() и MAX() используя первичный индекс в условиях архитектуры MVCC???? Чем принципиально MIN() и MAX() отличаются от COUNT() по алгоритму прохода всех записей? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Принципиально - ты по BTree-индексу можешь пойти направо и уткнуться в максимальный элемент. Пойдешь налево - и уткнешься в минимальный элемент. А вот количество листьев в BTree-дереве никакой алгоритм, кроме перебора, посчитать не сможет. А MSSQL - блочник, и следовательно, умеет правильно отслеживать количество элементов. Кстати, хинт: попробуйте в том же MSSQL получить COUNT во время выполнения какого-нибудь большого изменения количества записей. Мне почему-то кажется, что до завершения инсертов-делитов у вас не будет никаких результатов. А PG выдаст число на момент начала транзакции, в которой выполняется count(*) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2006, 19:23 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Кувалдин Роман А MSSQL - блочник, и следовательно, умеет правильно отслеживать количество элементов. MSSQL 2005 ни разу не блочник, а самый что ни на есть версионник. Другое дело, что никто не мешает хранить номер версии (грубо говоря) в индексе и определять видимость записи ключа не обращаясь к строке таблицы, но это ведёт к заметному распуханию индекса. Честно говоря, не знаю, каким образом эту задачу решил MS. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 08:39 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Master AlexА каким образом стали работать MIN() и MAX() используя первичный индекс в условиях архитектуры MVCC????Не стали. Пункт "Index Scan Backward using emails_pkey on emails" вовсе не означает, что делается выборка только по индексу. Для каждой найденной в индексе строки постгрес заглядывает в таблицу. Master AlexЧем принципиально MIN() и MAX() отличаются от COUNT() по алгоритму прохода всех записей?Для вычисления min или max не нужно проходить все записи, а надо найти одну крайнюю. Для вычисления count нужно проходить все записи. Кувалдин РоманА MSSQL - блочник, и следовательно, умеет правильно отслеживать количество элементов.Что значит "отслеживать количество элементов"? Судя по плану, который привел Master Alex в этом сообщении , MSSQL пробежал по индексу все 5 миллионов строк для вычисления count. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 10:15 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Andrew Sagulin MSSQL 2005 ни разу не блочник, а самый что ни на есть версионник. Другое дело, что никто не мешает хранить номер версии (грубо говоря) в индексе и определять видимость записи ключа не обращаясь к строке таблицы, но это ведёт к заметному распуханию индекса. Честно говоря, не знаю, каким образом эту задачу решил MS. Ошибаешься - он версионник "по запросу", т.е. ты должен стартовать транзакцию с указанием, что она будет работать со SNAPSHOT-ом (и только тогда версионность начинается). По-умолчанию же транзакции работают как в чистом блокировочнике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 10:50 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
т.е. план выполнения в MSSQL показанный выше - это план выполнения запроса блокировочником? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 11:08 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Funny_Falcon Ошибаешься - он версионник "по запросу", т.е. ты должен стартовать транзакцию с указанием, что она будет работать со SNAPSHOT-ом (и только тогда версионность начинается). По-умолчанию же транзакции работают как в чистом блокировочнике. Посыпаю голову пеплом ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 13:49 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Andrew Sagulin Посыпаю голову пеплом... Спасибо за линк. Прочитал и понял, что я тоже не совсем прав - я думал, что версионность это свойство запроса в MSSQL2005, а не базы... У меня снова появился к нему интерес :-) Впрочем версия грядущая версия PostgreSQL 8.2 мне очень нравится - уже скачал, уже потихоньку тестю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 10:26 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
LeXa NalBatСудя по плану, который привел Master Alex в этом сообщении , MSSQL пробежал по индексу все 5 миллионов строк для вычисления count. ... что возвращает нас к вопросу, а не быстрее ли было пробежаться по самой таблице? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2006, 15:58 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Кувалдин Роман ... что возвращает нас к вопросу, а не быстрее ли было пробежаться по самой таблице? Объемы разные: таблица 700МБ, индекс - 70MB - разница есть? Это в PostgreSQL при проходе по индексу нужно еще и таблицу проходить - а имеем ли мы право видеть эту строчку? В блокировочнике проще - все строчки в таблице ты имеешь право видеть, ибо существуют они в одной версии и блок стоит, а значит - одна строка в индексе соответствует одной строке в таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2006, 11:52 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Funny_Falcon Кувалдин Роман ... что возвращает нас к вопросу, а не быстрее ли было пробежаться по самой таблице? Объемы разные: таблица 700МБ, индекс - 70MB - разница есть? Это в PostgreSQL при проходе по индексу нужно еще и таблицу проходить - а имеем ли мы право видеть эту строчку? В блокировочнике проще - все строчки в таблице ты имеешь право видеть, ибо существуют они в одной версии и блок стоит, а значит - одна строка в индексе соответствует одной строке в таблице. Интересно, а почему в Оракле, который как известно версионник, известно, что если данные запроса можно получить из индекса (т.е. все нужные поля присутствуют в индексе), то в таблицу он (оракл) не полезет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2006, 11:23 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
pamirИнтересно, а почему в Оракле, который как известно версионник, известно, что если данные запроса можно получить из индекса (т.е. все нужные поля присутствуют в индексе), то в таблицу он (оракл) не полезет... Откуда известно? Оракл - это не пойми что. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2006, 13:30 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Кувалдин Роман pamirИнтересно, а почему в Оракле, который как известно версионник, известно, что если данные запроса можно получить из индекса (т.е. все нужные поля присутствуют в индексе), то в таблицу он (оракл) не полезет... Откуда известно? Оракл - это не пойми что. Из документации, из обучения. Я сейчас не приведу ссылок, т.к. занимаюсь ораклом не первый год и это просто у мне я в памяти. Если есть большие сомнения - можем сходить в оракловый форум и уточнить Что значит - оракл это не пойми что? Оракл как раз самый обычный версионник.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2006, 15:23 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
pamir Кувалдин Роман pamirИнтересно, а почему в Оракле, который как известно версионник, известно, что если данные запроса можно получить из индекса (т.е. все нужные поля присутствуют в индексе), то в таблицу он (оракл) не полезет... Откуда известно? Оракл - это не пойми что. Из документации, из обучения. Я сейчас не приведу ссылок, т.к. занимаюсь ораклом не первый год и это просто у мне я в памяти. Если есть большие сомнения - можем сходить в оракловый форум и уточнить Что значит - оракл это не пойми что? Оракл как раз самый обычный версионник.. Извиняюсь, вопрос был про "откуда известно, что версионник", а не "откуда известно, что он не полезет в таблицу", я же ответил на второе... Ну давайте сходим в оракловый форум. Только предварительно дадим определение понятию "версионник", чтобы потом не спорить о разном понимании этого термина. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2006, 15:24 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Кувалдин Роман pamirИнтересно, а почему в Оракле, который как известно версионник, известно, что если данные запроса можно получить из индекса (т.е. все нужные поля присутствуют в индексе), то в таблицу он (оракл) не полезет... Откуда известно? Оракл - это не пойми что. ну, не знаю, пойми он что, или не пойми, но как я неправильно /;0) понял из заявлений ораклоидов на местном ссайте (с год тому взад), оракл хранит не "номер версии в индексе" (и записях), а версии (измененных) страниц (точнее, для оракла -"блоков") индекса. Т.е. сам по себе "индекс не распухает" - в него не добавляется инфа о версии "в каждое значение", но структура хранения (всего и индексов в т.ч.) версифицируется поблочно (постранично). Таким образом, индекс каждой версии - актуален для нее. Мех-зм же получения актуальных версий одинаков для записей и индексов. прошу сильно не бить (темен, типо), но допросить ораклоидов. /;O) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2006, 15:34 |
|
||
|
PostgreSQL v8.2 beta1
|
|||
|---|---|---|---|
|
#18+
Перечитал эти прошлые распри , понял, что ничего в них про версии индекса оракла не разжовывается, а все я допридумал на основе невнятных (если приглядецца, а не домышлять) рассуждений участников. т.чтаа - мои извинения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2006, 19:03 |
|
||
|
|

start [/forum/topic.php?all=1&fid=53&tid=2006064]: |
0ms |
get settings: |
5ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
132ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 244ms |
| total: | 472ms |

| 0 / 0 |
