And maybe not on the wall, but instead in your SQLz, eating your data.

But a bit more seriously. Ever since PostgreSQL 8.4 we have window functions, but still I see people which do not know it or are wary to use it.

That’s why I decided to write a piece on window functions. How they work and what they can be used for.

Read more »

Some people are afraid of triggers.

Reasons for this are not really understandable for me, but I guess it stems from the fact that these are usually application developers, and not database admins. Or they encountered some kind of problem with triggers, and now they tend to think that triggers are inherently evil.

But they are not.

As virtually anything, triggers have some benefits, and some drawbacks. With a bit of thinking you can use them to do really cool things. But first you have to understand what exactly trigger is, how it works, and when to use which kind.

Read more »

Today there were some changes on explain.depesz.com – a bugfix, and functionality improvement.

Read more »

Last year I got cake in shape of Jameson cake. This year, I was surprised by cake being an idea of my dream-car Mitsubishi EVO:

It was fully edible (including 100% chocolate tires, and spoiler), and very good.

To the potential nay-sayers: I know it’s not really shape of Evo. But it had “three diamonds” on both front and back, clearly visible “Evo” signs, so it definitely counts

I use VIM. For more or less everything. Including writing blogposts.

Usually, when I was working on blogpost about PostgreSQL, I would write an sql file, switch to another console with psql running, run \i, get output, and then copy/paste the results to my blogpost in another vim.

It worked, but wasn’t really nice.

Today, I realized that I can do something much smarter.

I can just type in Vim, and then pass the data to psql, using simple “visual mapping”:

:vmap R :!psql -e<enter>

How does it work? When I’m in Vim, and I select (visual) some text, I press shift-R, and the selected blob is sent to psql.

Of course – psql has to know which database to connect to, as which user, and so on, but this is handled by setting PG* environment variables before running Vim.

Thanks to “-e” option, I get all the queries printed back to me, so I don’t lose them from my text file.

It works just great.

While I didn’t show it in the ascii cast, I can of course also run in this way multiple queries, use transactions, and everything else. The only problem might be that every such run is executed in new psql, which means that you don’t have single session.

But, that doesn’t seem to be big problem (at least for me).

It would be nice to have vim as full blown sql client, and I think it’s perfectly possible, but I just don’t care enough to spend time writing necessary scripts.

Yesterday on irc someone asked:

Hi, how do I get top 5 values from a column group by another column??

From further discussion, I learned that:

total rows in table is 2 million. It'll have unique words of less than 1 million.. (approx count)

I didn’t have time yesterday, but decided to write a solution, or two, to the problem.

Read more »

Recent release of new versions of PostgreSQL suggests that you do reindex of all indexes. But this will take a while, and since we don’t actually have ‘REINDEX CONCURRENTLY’ command – it’s a bit tricky.

So, since I will be doing this on several databases, decided to write a script that will handle the work for me.

Read more »

For those of you that don’t know – Tmux is program similar to screen, but written from scratch, with different functionality, approach, and capabilities.

I would like to show one particular case where I found that Tmux does something that screen doesn’t.

Read more »

Couple of days ago I had a problem that I couldn’t solve after ~ 2 hours, and decided to ask on IRC. Almost immediately after asking, I figured out the solution, but David asked me to write about the solution, even though it’s now (for me) completely obvious.

The problem was like this:

I had two tables, with very simple structure: event_when timestamptz, event_count int4, and wanted to show it as a single recordset with columns: event_when, event_count_a, event_count_b, but the problem was that event_when usually didn’t match. Here is an example:

Read more »

On 7th of August, Tom Lane committed patch:

Implement SQL-standard LATERAL subqueries.
 
This patch implements the standard syntax of LATERAL attached to a
sub-SELECT in FROM, and also allows LATERAL attached to a function in FROM,
since set-returning function calls are expected to be one of the principal
use-cases.
 
The main change here is a rewrite of the mechanism for keeping track of
which relations are visible for column references while the FROM clause is
being scanned.  The parser "namespace" lists are no longer lists of bare
RTEs, but are lists of ParseNamespaceItem structs, which carry an RTE
pointer as well as some visibility-controlling flags.  Aside from
supporting LATERAL correctly, this lets us get rid of the ancient hacks
that required rechecking subqueries and JOIN/ON and function-in-FROM
expressions for invalid references after they were initially parsed.
Invalid column references are now always correctly detected on sight.
 
In passing, remove assorted parser error checks that are now dead code by
virtue of our having gotten rid of add_missing_from, as well as some
comments that are obsolete for the same reason.  (It was mainly
add_missing_from that caused so much fudging here in the first place.)
 
The planner support for this feature is very minimal, and will be improved
in future patches.  It works well enough for testing purposes, though.
 
catversion bump forced due to new field in RangeTblEntry.

Read more »