Jeff Janes <jeff.ja...@gmail.com> writes:
> Using a RULE-based partitioning instead with row by row insertion, the
> plancache changes slowed it down by 300%, and this patch doesn't change
> that. But that seems to be down to the insertion getting planned
> repeatedly, because it decides the custom plan is cheaper than the generic
> plan. Whatever savings the custom plan may have are clearly less than the
> cost of doing the planning repeatedly.
That scenario doesn't sound like it has anything to do with the one being
discussed in this thread. But what do you mean by "rule-based
partitioning" exactly? A rule per se wouldn't result in a cached plan
at all, let alone one with parameters, which would be necessary to
trigger any use of the custom-cached-plan code path.
Test cases are way more interesting than hand-wavy complaints.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
