Re: Performance on Bulk Insert to Partitioned Table

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Performance on Bulk Insert to Partitioned Table
Дата
Msg-id CAFj8pRD5PvM+WaWFBcuFbnxpeZd--zygYoth2j82=nx0rBspEQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance on Bulk Insert to Partitioned Table  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-performance
2012/12/28 Stephen Frost <sfrost@snowman.net>:
> 2012/12/28 Vitalii Tymchyshyn <tivv00@gmail.com>:
>> Why so? Basic form "case lvalue when rvalue then out ... end" is much like
>> switch.
>
> Sorry, to be honest, I missed that distinction and didn't expect that to
> work as-is, yet apparently it does.  Does it currently perform the same
> as an if/elsif tree or is it implemented to actually use a table lookup?

both IF and CASE has very similar implementation - table lookup is not
used - there are not special path for searching constants

>
> * Pavel Stehule (pavel.stehule@gmail.com) wrote:
>> please, look to plpgsql source code. PL/pgSQL is too simply and has
>> not own arithmetic unit - all is transformed to SELECTs, has not any
>> optimization. But is really short and maintainable.
>
> I was thinking we'd actually do this for all CASE statements, those in
> plpgsql and those in regular SQL, if it's possible to do.  Hopefully
> it'd be possible to do easily in plpgsql once the SQL-level CASE is
> done.
>

I am not sure - SQL case is not heavy specially optimized too :(

I see only one possible way, do almost work when CASE statement is
parsed and bypass executor - this can work, but I afraid so it can
slowdown first start and some use cases where is not too much paths,
because we have to check all paths before executions.


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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Performance on Bulk Insert to Partitioned Table
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: Performance on Bulk Insert to Partitioned Table