Re: Performance on Bulk Insert to Partitioned Table - Mailing list pgsql-performance

From Pavel Stehule
Subject Re: Performance on Bulk Insert to Partitioned Table
Date
Msg-id CAFj8pRD5PvM+WaWFBcuFbnxpeZd--zygYoth2j82=nx0rBspEQ@mail.gmail.com
Whole thread Raw
In response to Re: Performance on Bulk Insert to Partitioned Table  (Stephen Frost <sfrost@snowman.net>)
List 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 by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Performance on Bulk Insert to Partitioned Table
Next
From: Jeff Janes
Date:
Subject: Re: Performance on Bulk Insert to Partitioned Table