From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Dong Ye <yed(at)vmware(dot)com> |
Subject: | Re: dynamic SQL - possible performance regression in 9.2 |
Date: | 2013-01-02 23:40:13 |
Message-ID: | 14816.1357170013@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Janes <jeff(dot)janes(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-01-03 01:35:00 | Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database" |
Previous Message | Jeff Janes | 2013-01-02 23:25:48 | Re: dynamic SQL - possible performance regression in 9.2 |