Re: proposal: integration bloat tables (indexes) to core

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: integration bloat tables (indexes) to core
Дата
Msg-id CAFj8pRBvyrA_-i56rqw2YTTv+fuVZWLVVg4e1NUGseFi5W8xkA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: integration bloat tables (indexes) to core  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
Дерево обсуждения


2016-06-16 20:31 GMT+02:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 6/13/16 12:16 PM, Tom Lane wrote:
At the same time, I'm pretty suspicious of putting stuff like this in
core, because the expectations for cross-version compatibility go up
by orders of magnitude as soon as we do that.

On a first go-round, I don't think we should add entire views, but rather functions that serve specific purposes. For table bloat that means a function that returns what the heap size should be based on pg_stats. For locking, it means providing information about which PID is blocking which PID. After that, most everything else is just window dressing.

could be

if you look on current bloating queries, then you can see pretty complex queries due implementation on high level. C implementation should be more faster. There are lot of changes in core, but these queries is working for PostgreSQL 8.2 to today, so they are relatively stable.

Regards

Pavel
 
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Следующее
От: Vik Fearing
Дата:
Сообщение: Re: proposal: integration bloat tables (indexes) to core