Благодарю!

и отучите ответственных писать схему, когда не надо

defaults are sane :)

я не понял проста сорри вопрос..

/me внезапно понял, что ни разу в жизни не смотрел схему в GUI

поразворачивай там до того, пока не будут видны все колонки таблицы

SELECT nspname || '.' || relname AS " relation " , pg_size_pretty ( pg_relation_size (C. oid ) ) AS "size " FROM pg_class C LEFT JOIN pg_namespace N ON (N. oid = C. relnamespace ) WHERE nspname = 'public' AND relname = 'Documents';

SELECT nspname || '.' || relname AS " relation " , pg_size_pretty ( pg_relation_size (C. oid ) ) AS "size " FROM pg_class C LEFT JOIN pg_namespace N ON (N. oid = C. relnamespace ) WHERE nspname = 'public' AND relname = 'Documents';

946 kB

а тост есть?

ну varchar(2500) точно в тост поедет

скорее всего, там ещё full description есть

всем привет Вопрос такой - надо N-мерные данные хранить и добавлять Кто-нибудь использует cube или есть другие решения для данной задачи?

всем привет Вопрос такой - надо N-мерные данные хранить и добавлять Кто-нибудь использует cube или есть другие решения для данной задачи?

какого рода N-мерные?

всем привет Вопрос такой - надо N-мерные данные хранить и добавлять Кто-нибудь использует cube или есть другие решения для данной задачи?

Это к Дарафею :)

ID" numeric(10,0) NOT NULL DEFAULT nextval('seq_docs'::regclass), "RegNum" character varying(100), — Регистрационный номер "RegDate" date, — Дата регистрации "FolderID" numeric(10,0), — Папка "ShortContent" character varying(2500), — Краткое содержание "DocumentTypeID" integer, — Тип документа (входящий, внутренний, исходящий и тд.) "JournalID" integer, — Журнал "DocumentKindID" integer, — Вид документа "LiterID" integer, — Литер "CreatorID" numeric(10,0), — Ñîçäàòåëü äîêóìåíòà "OutNum" character varying(100), — Исходящий номер "OutDate" date, — Дата исходящего документа "OrganizationID" integer, — Ссылка на корреспондента "FormID" integer, — Форма отправки "DepartmentID" integer, — Подразделение "AuthorID" numeric(10,0), — Автор документа "SignerID" numeric(10,0), — Подписант "InnerDate" date, — Внутренняя дата "InnerNum" character varying(40), — Внутренний номер "PersonName" character varying(100), — Контактное лицо "Address" character varying(300), — Адрес "DocDiscriminator" integer DEFAULT 368206494, — Дискриминатор используется Плоское наследование. "Deadline" date, — Срок "ComplaintTypeId" integer, "RegionID" integer, — Регион "ComplaintSubmWayID" integer, — Способ подачи обращения "ParentID" numeric(10,0), — Родительская жалоба "ComplaintStateID" integer, — Состояние обращения "DocumentName" character varying(1000), "FromHeadDocNum" character varying(100), "FromHeadMission" character varying(1000), "FromHeadDocDate" date, "ClosingDate" date, — Дата закрытия "ContractDocKindID" integer, "ContractKindID" integer, "ContractSum" numeric, — Сумма контракта (Количество * Цена) "ContractNumber" integer, — Номер "Count" numeric, — Количество "CurrencyID" integer, "ExecutorID" integer, "IsAnnulled" boolean DEFAULT false, — Аннулирован "Price" numeric, — ?ена "SendDate" date, — Дата отправки "ReceivedDate" date, — Дата получения "Controller" boolean, "Code" character varying(25), "Reason" character varying(1000), — Основание "JournalNumber" numeric(10,0), — Журнальный номер документа CONSTRAINT "PK_DocID" PRIMARY KEY ("ID"), CONSTRAINT "Documents_ComplaintSubmWayID_fkey" FOREIGN KEY ("ComplaintSubmWayID") REFERENCES public."Dictionaries" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "Documents_ComplaintTypeId_fkey" FOREIGN KEY ("ComplaintTypeId") REFERENCES public."Dictionaries" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_ContractDocKindId" FOREIGN KEY ("ContractDocKindID") REFERENCES public."Dictionaries" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_ContractKindId" FOREIGN KEY ("ContractKindID") REFERENCES public."Dictionaries" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_CurrencyId" FOREIGN KEY ("CurrencyID") REFERENCES public."Dictionaries" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_Document_AuthorId" FOREIGN KEY ("AuthorID") REFERENCES public."Staffs" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_Document_DepartmentID" FOREIGN KEY ("DepartmentID") REFERENCES public."Departments" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_Document_DicDocKindID" FOREIGN KEY ("DocumentKindID") REFERENCES public."Dictionaries" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_Document_DocTypeID" FOREIGN KEY ("DocumentTypeID") REFERENCES public."DocTypes" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT "FK_Document_FormID" FOREIGN KEY ("FormID") REFERENCES public."Dictionaries" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_Document_LiterID" FOREIGN KEY ("LiterID") REFERENCES public."Dictionaries" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT,

CONSTRAINT "FK_Document_OrganizationID" FOREIGN KEY ("OrganizationID") REFERENCES public."Organizations" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_Document_RegionID" FOREIGN KEY ("RegionID") REFERENCES public."Dictionaries" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_Document_SignerId" FOREIGN KEY ("SignerID") REFERENCES public."Staffs" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_Documents_ComplaintStateID" FOREIGN KEY ("ComplaintStateID") REFERENCES public."Dictionaries" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_Documents_CreatorID" FOREIGN KEY ("CreatorID") REFERENCES public."Staffs" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_Documents_JournalID" FOREIGN KEY ("JournalID") REFERENCES public."Journals" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT "FK_ExecutorID" FOREIGN KEY ("ExecutorID") REFERENCES public."Staffs" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT, CONSTRAINT "FK_ParentID" FOREIGN KEY ("ParentID") REFERENCES public."Documents" ("ID") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE CASCADE

а тост есть?

блин я не правильно написал сорри )) было "9464 kB"

946 kB

SELECT C. oid, nspname || '.' || relname AS " relation " , pg_size_pretty ( pg_relation_size (C. oid ) ) AS "size " FROM pg_class C LEFT JOIN pg_namespace N ON (N. oid = C. relnamespace ) WHERE nspname = 'public' AND relname = 'Documents'; и пришлите oid. По нему будем искать тост если он есть

oid 19110; relaition "public.Documents"; size text "9464 kB"

всем привет Вопрос такой - надо N-мерные данные хранить и добавлять Кто-нибудь использует cube или есть другие решения для данной задачи?

в общем, пока не опишешь природу данных - сложно что-то сказать мы написали свой тип для векторов под нашу семантику

SELECT nspname || '.' || relname AS " relation " , pg_size_pretty ( pg_relation_size (C. oid ) ) AS "size " FROM pg_class C LEFT JOIN pg_namespace N ON (N. oid = C. relnamespace ) WHERE nspname = 'pg_toast' AND relname like '%19110%';

"pg_toast.pg_toast_19110";"0 bytes" "pg_toast.pg_toast_19110_index";"8192 bytes"

"pg_toast.pg_toast_19110";"0 bytes" "pg_toast.pg_toast_19110_index";"8192 bytes"

пустые. Значит все влезло в таблицу.

oid 19110; relaition "public.Documents"; size text "9464 kB"

по идее вот ваш размер данных

vacuum full / cluster уже поделали? :)

да. а почему запрос на выборку так медлено работает я не понял это всё равно ))

vacuum full / cluster уже поделали? :)

нет а что это и как это делаеться

нет а что это и как это делаеться

VACUUM FULL "Documents";

Query returned successfully with no result in 1.0 secs.

Думаю 12 сек, это то, с чем придется жить :) Чтобы первое чтение с диска было тоже быстрое, можете воспользоваться вот этим - https://postgrespro.ru/docs/postgrespro/9.5/pgprewarm

попробовал, так, запрос выполняется за 6-10 секунд, хотя по плану 24мс, локально тоже долго выполняется, если в консоль выводить, если в файл то быстро 200мс

видимо время тратиться на "отобразить результаты"

да. Время на перегон всего этого добра по сети и отобразить.

локально тож долго))

а, хотя у вас локально все.(

да да)

Возможно оценки планировщика не верны, это может быть связано с seq_page_cost

хотя нет, локально 200мс, удаленно 10 сек, думаю действительно 16мбайт таблицу на передачу по сети тратиться

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

по сети не так долго тормоза при ворматировании выхлопа в консоль

в pg_admin последняя вкладка "История" там Total query runtime

в консольном клиенте так быстро не скажу

но точно должно гдето быть

не нахожу

в консольном \timing, который тоже учитывает рендеринг

ну или нет, но сеть точно меряет

Total query runtime: 52 msec

быстро так то

SELECT distinct on (date) some_id, date, type from table where type = 10 ORDER BY date; Всегда ли выдаст первый появившийся some_id где тип=10 ?

SELECT distinct on (date) some_id, date, type from table where type = 10 ORDER BY date; Всегда ли выдаст первый появившийся some_id где тип=10 ?

у вас id это sequence?

Нет, просто не уникальный айдишник

ERROR: S client not available

Хочу отловить первое появление айдишника с таким типом

тогда ответ - нет. Если у вас id bigint NOT NULL DEFAULT nextval('table_seq'::regclass) и date это какой то now() - то да

SELECT distinct on (date) some_id, date, type from table where type = 10 ORDER BY date; Всегда ли выдаст первый появившийся some_id где тип=10 ?

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

Наверное order by id, date еще поможет, но не факт

Вот тоже уверенности нет в сортировке дистинкта, не факт же что возьмет первую по ордеру

Вот тоже уверенности нет в сортировке дистинкта, не факт же что возьмет первую по ордеру

хотя на стаковерфлоу подобные примеры в лучших.

SELECT distinct on (some_id) some_id, date, type from table where type = 10 ORDER BY some_id, date; Отработал правильно. Всем спасибо.

http://thebuild.com/presentations/pgconfeu-2016-securing-postgresql.pdf

Добрый день! Господа есть такой вопрос. Какой тип данных вы бы мне по рекомендовали для использования primary key. Int or Guid. Спасибо.

Добрый день! Господа есть такой вопрос. Какой тип данных вы бы мне по рекомендовали для использования primary key. Int or Guid. Спасибо.

если можно int, то int :) а вообще вот http://gosimple.me/postgresql-primary-key-type-analysis/

Добрый день! Господа есть такой вопрос. Какой тип данных вы бы мне по рекомендовали для использования primary key. Int or Guid. Спасибо.

Попробуй boolean

Попробуй boolean

хорошо. ))

Я проста у вас ваше мнения хотел спросить.. Что вы используете и почему

Конечно int или bigint

Какой нафиг гуид

Конечно int или bigint

объясните почему int or bigint. Спасибо

конечно, гуид

потомучто гладиолус

как ещё на распределённых системах айдишки выдавать, не счётчиком же? :)

объясните почему int or bigint. Спасибо

Потому што размер индекса как минимум

как ещё на распределённых системах айдишки выдавать, не счётчиком же? :)

Может тогда bytea ?

bytea-то зачем?

в общем, или bigint, или guid если система живёт на одной ноде и на две никогда не вырастет - bigint если нет - guid

если вы задаётесь вопросом guid или bigint публично, то bigint

bytea-то зачем?

Ну... в sqlite это удобно было :)

есть же тип uuid, который внутри огромный инт