Skip site navigation (1) Skip section navigation (2)

Re: dynamic SQL - possible performance regression in 9.2

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 (view raw or flat)
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


In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2013-01-03 01:35:00
Subject: Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
Previous:From: Jeff JanesDate: 2013-01-02 23:25:48
Subject: Re: dynamic SQL - possible performance regression in 9.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group