On 25th of January, Alvaro Herrera committed patch:
Add pg_trigger_depth() function This reports the depth level of triggers currently in execution, or zero if not called from inside a trigger. No catversion bump in this patch, but you have to initdb if you want access to the new function. Author: Kevin Grittner
Some time ago I wrote about getting fast pagination. While fast, it had some problems which made it unusable for some. Specifically – you couldn't get page count, and easily jump to page number N.
I did some thinking on the subject, and I think I found a way to make it all work. Quite fast. And with not big overhead. Let me show you.
On 10th of October, Tom Lane committed patch by Deal Rasheed, which adds triggers on views:
Support triggers ON views. This patch adds the SQL-standard concept OF an INSTEAD OF TRIGGER, which IS fired instead OF performing a physical INSERT/UPDATE/DELETE. The TRIGGER FUNCTION IS passed the entire OLD AND/OR NEW ROWS OF the VIEW, AND must figure OUT what TO do TO the underlying TABLES TO implement the UPDATE. So this feature can be used TO implement updatable views USING TRIGGER programming STYLE rather than rule hacking. IN passing, this patch corrects the names OF SOME COLUMNS IN the information_schema.triggers VIEW. It seems the SQL committee renamed them somewhere BETWEEN SQL:99 AND SQL:2003. Dean Rasheed, reviewed BY Bernd Helmle; SOME additional hacking BY me.
On 28th of July, Simon Riggs committed patch which:
Log Message: ----------- Reduce LOCK levels OF CREATE TRIGGER AND SOME ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used FOR many altering DDL commands, allowing easier future changes OF LOCK levels. Implementation OF initial analysis ON DDL sub-commands, so that many LOCK levels are now at ShareUpdateExclusiveLock OR ShareRowExclusiveLock, allowing certain DDL NOT TO block reads/writes. FIRST OF NUMBER OF planned changes IN this area; additional docs required WHEN FULL project complete.
Continue reading Waiting for 9.1 – Reduced lock levels for ALTER TABLE
I have a mixed love/hate relationship with tests.
I hate writing them. I hate remembering to add them when I'm in the zone, and application code is flowing freely from the tips of my fingers.
But when I do add them, I absolutely love the ability to twist and replace the most core innards of application, and be able to tell that at least the sanity check of the code passes.
I love them even more when they prevent me for repeating some mistake/bug – i.e. when there is a bug, and I have tests (which clearly failed, as they didn't catch the bug), I add test for this specific bug, so I know that in future it will not happen again.
For a long time I've been fan of stored procedures (or functions) – of course not for everything, but where it makes sense.
Every now and then there is someone on IRC, mailing lists, or private contact which asks about rules.
My answer virtually always is: don't use rules. If you think that they solve your problem, think again. Why?
Continue reading To rule or not to rule – that is the question
One database that I am monitoring uses a lot of stored procedures. Some of them are fast, some of them are not so fast. I thought – is there a sensible way to diagnose which part of stored procedure take the most time?
I mean – I could just put the logic into application, and then every query would have it's own timing in Pg logs, but this is not practical. And I also believe that using stored procedures/functions is way better than using plain SQL due to a number of reasons.
So, I'm back to question – how to check which part of function takes most of the time?
Dynamic updates of fields in NEW in PL/pgSQL
Today, on #postgresql on IRC, strk asked about updating fields in NEW record, in plpgsql, but where name of the field is in variable.
After some time, he sent his question to hackers mailing list. And he got prompt reply that it's not possible.
Well, I dare to disagree.
Continue reading Stupid tricks – Dynamic updates of fields in NEW in PL/pgSQL
Please read also about this change in Pg 9.1, and this change in Pg 9.2 posts, as they explain that since Pg 9.1 some of the limitations listed in this post are no longer there.
Fight!
But more seriously – people tend to use various data types, and there have been some myths about them, so let's see how it really boils down.
First of all – All those data types are internally saved using the same C data structure – varlena.
Thanks to this we can be nearly sure that there are no performance differences. Are there no performance differences in reality? Let's test.
Continue reading CHAR(x) vs. VARCHAR(x) vs. VARCHAR vs. TEXT – UPDATED 2010-03-03
On 3rd of November Andrew Dunstan committed his patch which adds new function to PostgreSQL – suppress_redundant_updates_trigger().
This function is not for using in selects, but it can help you tremendously if your database access matches certain pattern.
Continue reading Waiting for 8.4 – suppress_redundant_updates_trigger