PERSISTANT PREPARE (another point of view)

Поиск
Список
Период
Сортировка
От Milan Oparnica
Тема PERSISTANT PREPARE (another point of view)
Дата
Msg-id BLU109-W5078B5ABDE57D183AA6695F8900@phx.gbl
обсуждение исходный текст
Ответы Re: PERSISTANT PREPARE (another point of view)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-sql
Hi,<br /><br />We are new to Postgre, actually we are migrating from MICROSOFT DBMS technologies to...hopefully
Postgre.<br/>Our company is involved in ERP business software in Serbia and region, currently counting over 200
clients.Some of them have DB's over 4GB in size.<br /><br />Reason for posting is implementation of PREPARE
statements.<br/>I've read a thread "# PREPARE and stuff PFC" on <font size="2">pgsql-performance 2007-06 list and I do
agreethat it would not gain performance issues.<br /><br />What could we gain by introducing a kind of global prepared
statementarea, is SIMPLICITY of DB DEVELOPMENT AND MAINTENANCE.<br /><br />Here is our point of view:<br /><br />We
havean application layer running over db layer. Application layer consists of classes and interfaces and db layer
containsdata and various data manipulation structures.<br />Application layer calls SQL statements expecting some
datasetsas results (inventory list for instance). What it doesn't care about is HOW is query built (sorting,
conditions,etc.) as long as it returns EXPECTED columns. Application simplly calls EXECUTE <statement>
(<param1>,<param2>...).Developers working application layer do not interfere with developers working on DB
andqueries. Plus MOST queries can be written to be reusable in various situations !!!<br /><br />The idea is: LETS
SEPARATESQL STATEMENTS FROM APPLICATION CODE.<br /><br />This way, we can introduce fine tuning to each of our clients
withouthaving to recompile our application. We can also work on improvements of queries performance and complexity
withoutrecompile of the application layer.<br /><br />Since one company has one set of rules PREPARED statements apply
toevery client connected to that database.<br /><br />Now, instead of preparing statements on each connection request
(andwe use around 900 prepared statements), why couldn't we simply prepare these statements ONCE and keep them in some
globalstorage for future everyday usage.<br /><br />We use this approach for forms & reports creation where Crystal
Reportengine creates outlined report based on static prepared statement.<br /><br />This approach is probably not
suitablefor large db systems with tons of data, but is very efficient in 90% of small and medium business size
databases.<br/><br />Please consider this issue when planning your WISH LIST or hopefully To-do-task-list.<br /><br
/>Illbe glad to here comments on this topic as well.<br /><br />Milan Oparnica<br />MELANY SOFWARE TEAM<br /></font><br
/><hr/>Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! <a
href="http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us"target="_new">Try
it!</a>

В списке pgsql-sql по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Unnecessary repeat condition for a self inner join
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PERSISTANT PREPARE (another point of view)