[DOCS] ModifyTable, EXPLAIN ANALYZE and AFTER triggers
Hi, The recent commit 09b49a8439fde63826f93f55430868cf2585644b claims: +Time spent firing triggers, if any, is charged to the Insert, +Update, or Delete node, and is also shown separately for each trigger. +Note, however, that deferred triggers will not be fired until end of +transaction and are thus not accounted for in the output of +EXPLAIN ANALYZE. But that's only part of the truth; the ModifyTable nodes queue AFTER triggers, but don't actually fire them. I remember there was some discussion during 9.0's development about making the ModifyTable nodes also count the time spent firing AFTER triggers, but I don't remember what we decided back then. Meanwhile, I think this part in the documentation needs a small clarification. Regards, Marko Tiikkaja -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] ModifyTable, EXPLAIN ANALYZE and AFTER triggers
Marko Tiikkaja writes: > The recent commit 09b49a8439fde63826f93f55430868cf2585644b claims: > +Time spent firing triggers, if any, is charged to the Insert, > +Update, or Delete node, and is also shown separately for each trigger. > +Note, however, that deferred triggers will not be fired until end of > +transaction and are thus not accounted for in the output of > +EXPLAIN ANALYZE. > But that's only part of the truth; the ModifyTable nodes queue AFTER > triggers, but don't actually fire them. I remember there was some > discussion during 9.0's development about making the ModifyTable nodes > also count the time spent firing AFTER triggers, but I don't remember > what we decided back then. Meanwhile, I think this part in the > documentation needs a small clarification. Oh, you're right --- I was thinking that the fireASTriggers call would actually execute the triggers, but of course it only queues them. Will fix. regards, tom lane -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Change to kernel-resources
On Mon, Feb 7, 2011 at 1:47 PM, Josh Berkus wrote: > Had to look up some stuff given the splintering of Solaris: > > == > > Solaris 2.6 to 2.9 (Solaris 6 to Solaris 9) > > The default maximum size of a shared memory segment is too low for > PostgreSQL. The relevant settings can be changed in /etc/system, for > example: What should we do with this material? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Change to kernel-resources
On 3/2/11 8:35 AM, Robert Haas wrote: > On Mon, Feb 7, 2011 at 1:47 PM, Josh Berkus wrote: >> Had to look up some stuff given the splintering of Solaris: >> >> == >> >> Solaris 2.6 to 2.9 (Solaris 6 to Solaris 9) >> >>The default maximum size of a shared memory segment is too low for >> PostgreSQL. The relevant settings can be changed in /etc/system, for >> example: > > What should we do with this material? Hmmm. I think there are probably still people using Solaris 9 out there, but not very many. Maybe we should move obscure OSes to the wiki, and have a link to the wiki in the docs? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Change to kernel-resources
On Wed, Mar 2, 2011 at 2:46 PM, Josh Berkus wrote: > On 3/2/11 8:35 AM, Robert Haas wrote: >> On Mon, Feb 7, 2011 at 1:47 PM, Josh Berkus wrote: >>> Had to look up some stuff given the splintering of Solaris: >>> >>> == >>> >>> Solaris 2.6 to 2.9 (Solaris 6 to Solaris 9) >>> >>> The default maximum size of a shared memory segment is too low for >>> PostgreSQL. The relevant settings can be changed in /etc/system, for >>> example: >> >> What should we do with this material? > > Hmmm. I think there are probably still people using Solaris 9 out > there, but not very many. > > Maybe we should move obscure OSes to the wiki, and have a link to the > wiki in the docs? I've got no problem putting it in the docs; in fact, I'd prefer it. But it'd be a lot easier to put it there if this were in the form of a patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Documenting removal of nonnullvalue() and friends
I wrote: > Bruce Momjian writes: >> Tom Lane wrote: >>> I thought about this a bit more last night. It's certainly true that >>> a lot of "internal" functions have comments that don't suggest that >>> they're not meant to be used directly. What I think would be a good >>> plan for functions that underlie operators is that we move any useful >>> comments from pg_proc to pg_operator, and then install a comment in >>> pg_proc that says "implementation of operator +" (or whatever the >>> operator name is). >>> ... >>> If that sounds like a reasonable plan, I'm willing to have a go at it >>> after the commitfest closes. >> Tom, any work on this? A TODO? > I haven't done anything about this yet, but it's still on my to-do list. Done now. regards, tom lane -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
