powered by simpleCommunicator - 2.0.40     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Голосуем за новые фичи PG
25 сообщений из 154, страница 2 из 7
Голосуем за новые фичи PG
    #37066200
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andron,

через pg_migrator. Но он еще сложный.
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37066296
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andron,

http://www.postgresql.org/docs/9.0/static/pgupgrade.html

---

но потом полный аналайз нужен)
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37066988
Weed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WeedВозможность указывать алиас таблицы в INSERT как в UPDATE и SELECT, например:

INSERT INTO tablitsa t (a,b,c) VALUES (1,2,3) RETURNING t.a, t.b, t.c;

Таки закатайте пожалуйста туда вот эту фичу? Это чистая косметика но она очень облегчает жизнь при написании рулесов.

У меня нету "баллов" или как их там, я вообще о сборе реквестов только от вас узнал.
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37066994
Weed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
РосгоснанораспилтрестWeedматематическая функция hypot(x, y)
Она есть в C math.h, очень удобно в геометрии юзать, ошибка меньше накапливается чем если через теорему Пифагора считать.

Так если есть - добавить её в Слона нет никакого труда. Пишешь свой C Extension - и всё отлично. Пишутся они очень легко, если хоть чуть-чуть знаешь С.

Там какой-то математический фокус используется. То есть, она не использует теорему Пифагора а делает этот поиск как-то проще. Я не силён в математике.

И нельзя ведь Сишную hypot() использовать, numeric сильно точнее double
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37067463
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Weed,

каждому персонально сразу даётся 10 балов и вам тоже :)

Нажимаете кнопочку VOTE напротив варианта, пишите меил какой-нить и имя и всё.
Давайте не ленитесь :)
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37067840
wbear
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хотелось бы что-то типа select ... with timeout '1 sec'; на запрос и глобальную/сессионную опцию лимитирующую время выполнения запроса на бекенде . Добавьте плз, а то с инглишем туго, боюсь опозориться :)
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37067884
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wbear, ,Уже есть триггер на вьюху.
Там можно писать полноценный код c NEW OLD полями
и языковыми конструкциями без извратов.
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37067887
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОКТОГЕНwbear, ,Уже есть триггер на вьюху.
Там можно писать полноценный код c NEW OLD полями
и языковыми конструкциями без извратов.
это weed-у
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37068674
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wbear,
автори глобальную/сессионную опцию лимитирующую время выполнения запроса на бекенде
statement_timeout - http://www.postgresql.org/docs/9.0/interactive/runtime-config-client.html

внимательнее надо к этим вопросам относиться
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37068743
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Misha Tyurinwbear,
автори глобальную/сессионную опцию лимитирующую время выполнения запроса на бекенде
statement_timeout - http://www.postgresql.org/docs/9.0/interactive/runtime-config-client.html

внимательнее надо к этим вопросам относиться

я всякие таймауты контролирую на пгбоунсере http://pgbouncer.projects.postgresql.org/doc/config.html#_connection_sanity_checks_timeouts
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37068854
wbear
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ой ё, таки опозорился :) , зато пропала уверенность в том, что доки я читал внимательно. спасбо
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37069161
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wbear, уточню.
http://www.pgadmin.org/development/changelog.php 2010-11-07 GL 1.14.0 Add support for 9.1 new kind of trigger: INSTEAD OF.
Это относится к вьюхам.
Подробнее тут
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37070712
wbear
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОКТОГЕН,

да уже, в подпись поставь себе авторэто weed-у
:)
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37070777
Big Andy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andron,

По крайней мере так заявлено. Я, например не рискнул. Даже для тестовой БД.
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37076956
Фотография Andron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А скажите есть ли в PostgreSQL ограниченные режимы для базы? Например "административный" режим, допускающий работу только определенных пользователей с базой. Штука нужная думаю, и во многих базах она есть. Или например перевод в read-only режим, допускающий только чтение базы.
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37076989
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andron,"административный" режим эмулируется подменой hba.conf
с соответствующими пользователями и reload-ом сервера.
Режим "только чтение", в частности, есть у slave-машин при репликации.
Надо просто перевести ПЖ в этот режим.
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37077045
Фотография Andron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОКТОГЕН,

это не то. Представьте - надо перестартовать сервер, менять конфиги. Неудобно. Было бы неплохо делать это без перезагрузки и одной командой.
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37077104
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andron, reload это не рестарт.
Вы можете написать скрипт, который это делает.
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37086888
Игорь Куршаков
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Забросил идею насчет виртуальных столбцов по аналогии с виртуальными функциями классов.

Пусть столбец декларируется в предке, а определяется в наследниках - всякий раз по-разному.
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37087302
Игорь Куршаков, что-то торможу сильно.
Можно пару примеров, когда это реально полезно?
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37087363
Игорь Куршаков
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ПодпольщегИгорь Куршаков, что-то торможу сильно.
Можно пару примеров, когда это реально полезно?

Наследование таково, что наследник получает в наследство колонки предка.
А предок получает все записи наследника - но только те поля, что в нем определены.
К дополнительным полям, определенным в наследнике, у него нет доступа без дополнительных SELECT.

Суть идеи - чтоб доступ был к каким-то полям, которые определяются в наследнике как вычисляемые. Если есть запись от наследника, где поле не определено - то NULL.

То есть, мы работаем с предком и при этом оперируем какой-то инфой от наследников. Причем сразу. Причем с учетом партицирования через CHECK

Что касается примера, то http://www.sql.ru/forum/actualthread.aspx?tid=820849

В данном примере было иерархическое дерево с партицированием по типу узла. Благодаря тому, что все связи id-parent определяются на уровне предка, мы можем работать с деревом как с одной базой, хотя оно раскидано по таблицам типов узлов. Однако, для программы-клиента надо иметь строку с именем узла (чтоб построить дерево). А вот имя может быть разным, в зависимости от наследника. Имя вычисляемое, в зависимости от полей наследника.

И поскольку выборка из предка не дает нам полей наследников, то надо или делать дополнительный SELECT при выборке каждой записи дерева. Или делать поле-строку в предке и модифицировать ее триггерами, подвязанными к каждому наследнику.

В общем, или медленно или жирно.

Тогда как при реализованных виртуальных колонках можно было бы их задекларировать в предке, описать в наследнике и при запросах к предку сразу быстро вычислять и отдавать.
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37207256
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мне вот тут подумалось, что было бы очень не плохо иметь возможность в рамках кластера некоторые таблицы и/или индексы "принудительно" всегда держать в буферах.

это бы давало в определенных случаях более точную оценку по времени на запрос. что очень полезно при "многопрофильной" базе. почему бы в ней не выделить памяти под очень горячии но редко запрашиваемые данные.

причем можно было бы придумать либо ленивое туда залезание либо сразу при старте. либо ограничивать такой "невыгружаемый" пул буферов и в нём уже проводить ротацию или не ограничивать, пусть хоть всё сожрет.

как вам?
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37207305
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Misha Tyurinв рамках кластера некоторые таблицы и/или индексы "принудительно" всегда держать в буферах.
+1
Очень было бы полезно. Подчас разовый сервисный запрос выбивает кеш, хотя его время исполнения совершенно не критично.
Вроде бы Oracle позволяет подкручивать параметры кширования per object.Где-то слышал...
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37207431
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tadmin,

неее.... немного не то. вот как раз "разовый" запрос ничего не "выбивает", ибо там двухуровневый механизм. есть очередь ограниченной длинны первого уровня ("тёпленькое") и уже сами лру буфера на втором (то, что в "горячее" пролезло). вот тут это почитать в частности можно http://www.sai.msu.su/~megera/postgres/talks/what_is_postgresql.html - Управление буферами в PostgreSQL - там есть параграф.

вот если много "сервисных" подряд - то да, они могут перекосить распределение. (вот через это можно смотреть http://www.postgresql.org/docs/9.0/static/pgbuffercache.html )

меня же больше такая ситуация беспокоит. вот, например, олтп база, много больше по размеру, чем оперативка, всё работает хорошо так как "рабочий" набор постоянно почти полностью в неё влазит, ну там страницы в нём ротируются - "древнее" "тонет", новое "всплывает". база хорошо настроена, всё мониторится, обслуживается, бекапируется, архивируется, реплицируется и прочее. работает годами.

и вот мы НЕ хотим НОВЫЙ кластер разворачивать, нам этот нравится, как всё там уже вокруг него классно сделано и всё на него настроено. но нам нужна новая фича, она требует чтобы небольшой быстрый индекс висел весь в памяти. запросы РЕДКИЕ и РЕНДОМНЫЕ к томуже по пробитию. но и требование, чтобы были максимально быстрыми всегда, без "прогревочного круга" - задача подстановок "налету".

прогревать всё руками по расписаниям - городить этого не хочется. вот и приходим к выводу разворачивать еще один постгресс - а это сразу несколько машин и обвязки и прочее. или писать собственные велосипедные "деревья" и "джины" со всеми вытекающими. жуть.

так что вот, в чем у меня вопросы возникли.
...
Рейтинг: 0 / 0
Голосуем за новые фичи PG
    #37207649
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tmpfs с триггерным управлением не пробовали?
...
Рейтинг: 0 / 0
25 сообщений из 154, страница 2 из 7
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Голосуем за новые фичи PG
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]