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 по дате отправления: