Re: Practical question. - Mailing list pgsql-general

From louis gonzales
Subject Re: Practical question.
Date
Msg-id 45FC6D91.6000506@linuxlouis.net
Whole thread Raw
In response to Re: Practical question.  ("hubert depesz lubaczewski" <depesz@gmail.com>)
Responses Re: Practical question.  (louis gonzales <gonzales@linuxlouis.net>)
Re: Practical question.  ("hubert depesz lubaczewski" <depesz@gmail.com>)
List pgsql-general
Dear Hubert,<br /> Two things<br /> 1) <u><b>"statement-level" and "row-level" straight from PostgreSQL: <a
class="moz-txt-link-freetext"
href="http://www.postgresql.org/docs/8.1/interactive/trigger-datachanges.html">http://www.postgresql.org/docs/8.1/interactive/trigger-datachanges.html</a></b></u><br
/><ul><li><p><u><b>Statement-leveltriggers</b></u> follow simple visibility rules: none of the changes made by a
statementare visible to statement-level triggers that are invoked before the statement, whereas all modifications are
visibleto statement-level after triggers. <li><p>The data change (insertion, update, or deletion) causing the trigger
tofire is naturally <span class="emphasis"><i class="EMPHASIS">not</i></span> visible to SQL commands executed in a
row-levelbefore trigger, because it hasn't happened yet. <li><p>However, SQL commands executed in a row-level before
trigger<span class="emphasis"><i class="EMPHASIS">will</i></span> see the effects of data changes for rows previously
processedin the same outer command. This requires caution, since the ordering of these change events is not in general
predictable;a SQL command that affects multiple rows may visit the rows in any order. <li><p>When a
<u><b>row-level</b></u>after trigger is fired, all data changes made by the outer command are already complete, and are
visibleto the invoked trigger function. </ul> 2) Seeing as you have no idea - not attacking, stating fact - on the
rationalebehind the "insert statement-level" to create 1-to-1 table for each statement-level <br /> insert, I'd say
yourpresumption is unfounded.  If you have some benchmark data, which support why/how to quantify, 50K records in a
singletable, all of which would have N number of associated records in another table, would out perform 50K records in
asingle table referencing dedicated 'small' tables, please do share.<br /><br /> Thanks though.<br /><br /> hubert
depeszlubaczewski wrote: <blockquote cite="mid9e4684ce0703162139r7bc64180ga47e854af9678967@mail.gmail.com"
type="cite">On3/16/07, louis gonzales <a class="moz-txt-link-rfc2396E"
href="mailto:gonzales@linuxlouis.net"><gonzales@linuxlouis.net></a>wrote: <br /><blockquote type="cite">I want to
writea <big><big><big><b>statement-level</b></big></big></big> trigger - one that happens once per <br /> statement -
suchthat, immediately after an insert into a table(which <br /> gets a unique integer value as an ID from a defined
sequence,being the <br /> primary key on the table), a new table is created with foreign key <br /> constraint on that
uniqueID. <br /></blockquote><br /> hi, <br /> i think what you;re trying to do is wrong - having that many tables <br
/>simply cannot work properly. <br /> additionally - i think you're misinformed. the kind of action you <br /> would
liketo "trigger on" is not "per statement" but "per row". <br /> example: <br /> insert into table x (field) select
other_fieldfrom other_table; <br /> if this insert would insert 10 records - "once per statement" trigger <br /> would
becalled only once. <br /><br /> but anyway - what you're proposing will lead to many, many problems. <br /> (plus it
willnever scale correctly). <br /><br /> depesz <br /></blockquote><br /><br /><pre class="moz-signature" cols="72">--

Email:    <a class="moz-txt-link-abbreviated"
href="mailto:louis.gonzales@linuxlouis.net">louis.gonzales@linuxlouis.net</a>
WebSite:  <a class="moz-txt-link-freetext" href="http://www.linuxlouis.net">http://www.linuxlouis.net</a>
"Open the pod bay doors HAL!" -2001: A Space Odyssey
"Good morning starshine, the Earth says hello." -Willy Wonka
</pre>

pgsql-general by date:

Previous
From: Tino Wildenhain
Date:
Subject: Re: Postgres Database size
Next
From: "Tomi N/A"
Date:
Subject: Re: Postgres Database size