Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54847

FreemanZAV
А как, например, многократно использовать какую-нибудь тяжёлую выборку,
если в PG подзапросы не материализуются?

Временные таблицы для этого есть.

Posted via ActualForum NNTP Server 1.5

6 ноя 12, 16:31    [13427934]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Dimitry Sibiryakov
FreemanZAV
А как, например, многократно использовать какую-нибудь тяжёлую выборку,
если в PG подзапросы не материализуются?

Временные таблицы для этого есть.


Собственно тынца я и просил всю дорогу. А мне говорили про какие-то view. Я просто подзабыл, что механизм временных таблиц в PG не такой, как в oracle, например. В PG есть LOCAL TEMP TABLE ON COMMIT DROP, что вполне может заменить табличные переменные
6 ноя 12, 16:49    [13428124]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
FreemanZAV
Dimitry Sibiryakov
пропущено...

Временные таблицы для этого есть.


Собственно тынца я и просил всю дорогу. А мне говорили про какие-то view. Я просто подзабыл, что механизм временных таблиц в PG не такой, как в oracle, например. В PG есть LOCAL TEMP TABLE ON COMMIT DROP, что вполне может заменить табличные переменные


Хотя не уверен
6 ноя 12, 17:03    [13428257]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
Зайцев Фёдор
Member

Откуда: Лужки
Сообщений: 5308
FreemanZAV
В PG есть LOCAL TEMP TABLE ON COMMIT DROP, что вполне может заменить табличные переменные

и в качестве параметра функции можно передать?
6 ноя 12, 17:04    [13428266]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Зайцев Фёдор
FreemanZAV
В PG есть LOCAL TEMP TABLE ON COMMIT DROP, что вполне может заменить табличные переменные

и в качестве параметра функции можно передать?


Нет необходимости. Таблица будет видна всем вызываемым функциям (хотя не очень кошерно). Но, в отличие от табличных переменных, таблица не будет Readonly.
6 ноя 12, 17:08    [13428291]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54847

FreemanZAV
Таблица будет видна всем вызываемым функциям (хотя не очень кошерно).

Функция, обрабатывающая заранее неизвестную таблицу, некошерна сама по себе.

Posted via ActualForum NNTP Server 1.5

6 ноя 12, 17:51    [13428575]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Dimitry Sibiryakov
FreemanZAV
Таблица будет видна всем вызываемым функциям (хотя не очень кошерно).

Функция, обрабатывающая заранее неизвестную таблицу, некошерна сама по себе.

Нет в жизни совершенства. В PG нет табличных переменных, в MSSQL они есть, но передать их по человечески в другую функцию нельзя.

А касаемо вопроса про табличные переменные в MSSQL:
mad_nazgul
Зачем?! Если есть таблицы?


Тот же вопрос можно задать про массивы в PG.
6 ноя 12, 21:12    [13429324]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
Ёш
Member

Откуда:
Сообщений: 2892
FreemanZAV
А как, например, многократно использовать какую-нибудь тяжёлую выборку, если в PG подзапросы не материализуются?

Зависит от плана, может и материализовать :)

explain with b as (select * from b) select count(1) from a join b using(n);
                              QUERY PLAN                               
-----------------------------------------------------------------------
 Aggregate  (cost=360685.00..360685.01 rows=1 width=0)
   CTE b
     ->  Seq Scan on b  (cost=0.00..145.00 rows=10000 width=4)
   ->  Nested Loop  (cost=0.00..360240.00 rows=120000 width=0)
         Join Filter: (a.n = b.n)
         ->  CTE Scan on b  (cost=0.00..200.00 rows=10000 width=4)
         ->  Materialize  (cost=0.00..46.00 rows=2400 width=4)
               ->  Seq Scan on a  (cost=0.00..34.00 rows=2400 width=4)
6 ноя 12, 21:58    [13429469]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Ёш
FreemanZAV
А как, например, многократно использовать какую-нибудь тяжёлую выборку, если в PG подзапросы не материализуются?

Зависит от плана, может и материализовать :)

explain with b as (select * from b) select count(1) from a join b using(n);
                              QUERY PLAN                               
-----------------------------------------------------------------------
 Aggregate  (cost=360685.00..360685.01 rows=1 width=0)
   CTE b
     ->  Seq Scan on b  (cost=0.00..145.00 rows=10000 width=4)
   ->  Nested Loop  (cost=0.00..360240.00 rows=120000 width=0)
         Join Filter: (a.n = b.n)
         ->  CTE Scan on b  (cost=0.00..200.00 rows=10000 width=4)
         ->  Materialize  (cost=0.00..46.00 rows=2400 width=4)
               ->  Seq Scan on a  (cost=0.00..34.00 rows=2400 width=4)
а если он еще сотни строчек занимает? А если он результат нескольких запросов?
6 ноя 12, 23:10    [13429714]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5825
Зайцев Фёдор
вы что-то путаете - нужны таблицы, которые ведут себя как переменные.
у вас такие есть?


Зачем?!
Когда есть
1) Таблицы
2) Функции
7 ноя 12, 07:29    [13430363]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5825
FreemanZAV
А как, например, многократно использовать какую-нибудь тяжёлую выборку, если в PG подзапросы не материализуются?


Э-э-э.... А в чем проблема использовать тяжелую выборку?
Как минимум план запроса строиться и последующие запросы к такой выборке будут быстрее.
Т.е. ощущение, что табличные переменные - "костыль" меня не покидают. :-)
7 ноя 12, 07:34    [13430368]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5825
Зайцев Фёдор
FreemanZAV
В PG есть LOCAL TEMP TABLE ON COMMIT DROP, что вполне может заменить табличные переменные

и в качестве параметра функции можно передать?


Можно... вот только как массив. ;-)
7 ноя 12, 07:37    [13430373]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5825
Dimitry Sibiryakov
FreemanZAV
Таблица будет видна всем вызываемым функциям (хотя не очень кошерно).

Функция, обрабатывающая заранее неизвестную таблицу, некошерна сама по себе.


Наследование ;-)
Т.е. можно обрабатывать только то что известно.
7 ноя 12, 07:39    [13430377]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
mad_nazgul


Э-э-э.... А в чем проблема использовать тяжелую выборку?


Чтобы понять, в чём проблема тяжёлых выборок, можно например почитать про хинт materialize в oracle - что он делает и для чего он нужен.

mad_nazgul
Т.е. ощущение, что табличные переменные - "костыль" меня не покидают. :-)

В сущности как и массивы
7 ноя 12, 09:41    [13430657]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
mad_nazgul
Зайцев Фёдор
вы что-то путаете - нужны таблицы, которые ведут себя как переменные.
у вас такие есть?


Зачем?!
Когда есть
1) Таблицы
2) Функции


Ещё раз могу объяснить. Табличные переменные по сути являются временными таблицами, только их можно объявлять внутри процедур как переменные и передавать из процедуры в процедуру. Зачем нужны временные таблицы объяснять надо?
7 ноя 12, 09:49    [13430722]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Ёш
FreemanZAV
А как, например, многократно использовать какую-нибудь тяжёлую выборку, если в PG подзапросы не материализуются?

Зависит от плана, может и материализовать :)

explain with b as (select * from b) select count(1) from a join b using(n);
                              QUERY PLAN                               
-----------------------------------------------------------------------
 Aggregate  (cost=360685.00..360685.01 rows=1 width=0)
   CTE b
     ->  Seq Scan on b  (cost=0.00..145.00 rows=10000 width=4)
   ->  Nested Loop  (cost=0.00..360240.00 rows=120000 width=0)
         Join Filter: (a.n = b.n)
         ->  CTE Scan on b  (cost=0.00..200.00 rows=10000 width=4)
         ->  Materialize  (cost=0.00..46.00 rows=2400 width=4)
               ->  Seq Scan on a  (cost=0.00..34.00 rows=2400 width=4)


Да, ошибался. Умеет.
7 ноя 12, 10:10    [13430819]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
FreemanZAV
Ёш
пропущено...

Зависит от плана, может и материализовать :)

explain with b as (select * from b) select count(1) from a join b using(n);
                              QUERY PLAN                               
-----------------------------------------------------------------------
 Aggregate  (cost=360685.00..360685.01 rows=1 width=0)
   CTE b
     ->  Seq Scan on b  (cost=0.00..145.00 rows=10000 width=4)
   ->  Nested Loop  (cost=0.00..360240.00 rows=120000 width=0)
         Join Filter: (a.n = b.n)
         ->  CTE Scan on b  (cost=0.00..200.00 rows=10000 width=4)
         ->  Materialize  (cost=0.00..46.00 rows=2400 width=4)
               ->  Seq Scan on a  (cost=0.00..34.00 rows=2400 width=4)


Да, ошибался. Умеет.


Хотя процесс не управляемый.
7 ноя 12, 10:17    [13430872]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
FreemanZAV
Ещё раз могу объяснить. Табличные переменные по сути являются временными таблицами, только их можно объявлять внутри процедур как переменные и передавать из процедуры в процедуру. Зачем нужны временные таблицы объяснять надо?

Чем массивы плохи? Создавай какие хочешь типы записей и перегоняй массивами как и куда хочешь.
WITH tst AS
(
	SELECT array_agg(t.*) AS test
	FROM public.tbl1 t
)
SELECT ((unnest(tst.test))::public.tbl1).*  FROM tst

Свёртка и развёртка таблицы из массива
7 ноя 12, 12:07    [13431857]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Вместо массива типов записей конкретной таблицы можно подставить любую запись, которая описана как составной тип.
Не хочется объявлять типы - можно создать двумерные массивы текста и, передавая в/из процедуру, преобразовывать во что
хочешь. Это несколько громоздко, но тоже правомерно.
7 ноя 12, 12:12    [13431911]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
ОКТОГЕН
Вместо массива типов записей конкретной таблицы можно подставить любую запись, которая описана как составной тип.
Не хочется объявлять типы создавать таблицы - можно создать двумерные массивы текста и, передавая в/из процедуру, преобразовывать во что
хочешь. Это несколько громоздко, но тоже правомерно.

FIXED
7 ноя 12, 12:27    [13432052]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
ОКТОГЕН

Чем массивы плохи? Создавай какие хочешь типы записей и перегоняй массивами как и куда хочешь.


Не поддерживают DML, например.
7 ноя 12, 12:54    [13432319]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
FreemanZAV
ОКТОГЕН

Чем массивы плохи? Создавай какие хочешь типы записей и перегоняй массивами как и куда хочешь.


Не поддерживают DML, например.


Я уже вроде говорил.
7 ноя 12, 12:55    [13432327]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5825
FreemanZAV
mad_nazgul
Т.е. ощущение, что табличные переменные - "костыль" меня не покидают. :-)

В сущности как и массивы


Ну массивы идут от концепции ООБД.
PostgreSQL как бы ООБД (хотя и не совсем)
Соответственно в нем можно реализовать любой тип, в том числе и массив

Так что это не костыль, а вполне концептуальное решение.
Вопрос только в другом, на сколько концепция ООБД соотноситься с СУРБД.
Думаю это уже философский вопрос.
8 ноя 12, 10:44    [13437845]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
mad_nazgul
FreemanZAV
пропущено...

В сущности как и массивы


Ну массивы идут от концепции ООБД.
PostgreSQL как бы ООБД (хотя и не совсем)
Соответственно в нем можно реализовать любой тип, в том числе и массив

Так что это не костыль, а вполне концептуальное решение.
Вопрос только в другом, на сколько концепция ООБД соотноситься с СУРБД.
Думаю это уже философский вопрос.


Ну тогда костылём можно считать всю концепцию ООБД.
8 ноя 12, 11:28    [13438171]     Ответить | Цитировать Сообщить модератору
 Re: ...и снова MSSQL 2008 R2 vs PostgreSQL  [new]
какбе
Guest
FreemanZAV
FreemanZAV
пропущено...


Да, ошибался. Умеет.


Хотя процесс не управляемый.
какбе CTE до последнего всегда именно и только материализовывался. будет ли это изменено - не уверен.

т.е. если хотите материализовать - делаете через CTE (WITH) если на усмотрение оптимайзера - то через подзапрос "в старом стиле". т.е. жесткая "управляемая" материализация через CTE существует.
8 ноя 12, 12:21    [13438691]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить