Обсуждение: Performance on writable views
Hi folks, I'm often using writable views as interfaces to clients, so they only see "virtual" objects and never have to cope with the actual storage, ie. to give some client an totally denormalized view of certain things, containing only those information required for certain kind of operations. This method is nice for creating easy and robust client interfaces - internal schema changes are not visible to the client. In situations when many, many clients - often coded/maintained by different people - have to access an database which is still under development (typical for many inhouse applications), it helps to circument interface instabilities. Now I've got the strange feeling that this makes updates slow, since it always has to run the whole view query to fetch an record to be updated (ie. to get OLD.*). Could anyone with some deep insight please give me some details about that issue ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------
Enrico Weigelt wrote: > I'm often using writable views as interfaces to clients, so > they only see "virtual" objects and never have to cope with > the actual storage, ie. to give some client an totally > denormalized view of certain things, containing only those > information required for certain kind of operations. > > This method is nice for creating easy and robust client > interfaces - internal schema changes are not visible to > the client. In situations when many, many clients - often > coded/maintained by different people - have to access an > database which is still under development (typical for > many inhouse applications), it helps to circument interface > instabilities. > > Now I've got the strange feeling that this makes updates > slow, since it always has to run the whole view query to > fetch an record to be updated (ie. to get OLD.*). There is some overhead in rewriting the query, but it shouldn't be significantly slower than issuing the statements behind the view directly. I wouldn't worry about it, unless you have concrete evidence that it's causing problems. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Heikki Linnakangas wrote:
> Enrico Weigelt wrote:
>> I'm often using writable views as interfaces to clients, so
>> they only see "virtual" objects and never have to cope with
>> the actual storage, ie. to give some client an totally
>> denormalized view of certain things, containing only those
>> information required for certain kind of operations.
>> Now I've got the strange feeling that this makes updates
>> slow, since it always has to run the whole view query to
>> fetch an record to be updated (ie. to get OLD.*).
>
> There is some overhead in rewriting the query, but it shouldn't be
> significantly slower than issuing the statements behind the view
> directly. I wouldn't worry about it, unless you have concrete evidence
> that it's causing problems.
I don't know about that, at least when using rules for partitioning the
impact can be significant in comparison to triggers.
It may make sense for him to push this stuff to stored procs instead.
Joshua D. Drake
- --
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGvcCRATb/zqfZUUQRAqngAKCKZG1LkeBd6/Qyghv/GzPBp4qCGACfS1Ar
tXJSi/ynIQlAkATIv2yKd7M=
=lYbI
-----END PGP SIGNATURE-----
On Aug 11, 2007, at 8:58 AM, Joshua D. Drake wrote: > Heikki Linnakangas wrote: >> Enrico Weigelt wrote: >>> I'm often using writable views as interfaces to clients, so >>> they only see "virtual" objects and never have to cope with >>> the actual storage, ie. to give some client an totally >>> denormalized view of certain things, containing only those >>> information required for certain kind of operations. > >>> Now I've got the strange feeling that this makes updates >>> slow, since it always has to run the whole view query to >>> fetch an record to be updated (ie. to get OLD.*). >> >> There is some overhead in rewriting the query, but it shouldn't be >> significantly slower than issuing the statements behind the view >> directly. I wouldn't worry about it, unless you have concrete >> evidence >> that it's causing problems. > > I don't know about that, at least when using rules for partitioning > the > impact can be significant in comparison to triggers. That's because you have to re-evaluate the input query for each rule that's defined, so even if you only have rules for 2 partitions in a table (which is really about the minimum you can have, at least for some period of overlap surrounding the time when you switch to a new partition), you're looking at evaluating every input query twice. In this case, the rules presumably are just simply re-directing DML, so there'd only be one rule in play at a time. That means the only real overhead is in the rewrite engine. -- Decibel!, aka Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)