pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Jim Nasby <decibel@decibel.org>
To: Joshua D. Drake <jd@commandprompt.com>
Cc: Heikki Linnakangas <heikki@enterprisedb.com>
Cc: pgsql-sql <pgsql-sql@postgresql.org>
Cc: postgresql performance list <pgsql-performance@postgresql.org>
Subject: Re: Performance on writable views
Date: Mon, 13 Aug 2007 17:17:16 -0500
Message-ID: <6F774767-8871-45DC-AE31-FD3D7A5A2F46@decibel.org> (raw)
In-Reply-To: <46BDC091.4090109@commandprompt.com>
References: <20070808124054.GC27936@nibiru.local>
	<46BD687E.1040100@enterprisedb.com>
	<46BDC091.4090109@commandprompt.com>

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)





view thread (4+ messages)

Message-ID: <6F774767-8871-45DC-AE31-FD3D7A5A2F46@decibel.org>
Permalink:  ../6F774767-8871-45DC-AE31-FD3D7A5A2F46@decibel.org/
Also on:    postgresql.org/message-id/6F774767-8871-45DC-AE31-FD3D7A5A2F46@decibel.org

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: decibel@decibel.org, jd@commandprompt.com, heikki@enterprisedb.com, pgsql-performance@postgresql.org
  Subject: Re: Performance on writable views
  In-Reply-To: <6F774767-8871-45DC-AE31-FD3D7A5A2F46@decibel.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox