PostgreSQL Training,
Consulting & Support
General Bits
By A. Elein Mustain

19-July-2004 Issue: 80

Archives | General Tidbits | Google General Bits | Docs | Castellano | PortuguÍs | Subscriptions | Notifications | | Prev

General Bits is a column loosely based on the PostgreSQL mailing list pgsql-general.
To find out more about the pgsql-general list and PostgreSQL, see

Off to OSCON next week
Next Issue 18-July-2004

Next week there will be no new issue of General Bits. I will be at the O'Reilly Open Source Conference in Portland, Oregon.

I hope to meet some of you there!

Editor: elein at
Portuguese Translations
Welcome Pedro B. 17-Jul-2004

General Bits has issues recent issues translated into both Castellano and Portuguese.

Pedro B. has graciously joined our team of esteemed translators to begin translating General Bits into Portuguese, as distinct our previous translations into Brasilian-Portuguese.

Alvaro Herrera continues to be our Castellano translator even as he is coding features for the upcoming 7.5 release and helping translate the documentation.

We are still looking for another Brasilian-Portuguese translator as Juliano Da Silva has been unable to continue due to time constraints.

The translators' work requires a good deal of time and commitment as well as good knowledge of languages and, of course, PostgreSQL. This unpaid work is our way of contributing back into the PostgreSQL community.

Editor: elein at
Arithmetic on Aggregate Expressions
[GENERAL] Column as result of subtraction of two other columns? 16-Jul-2004

The following selection will not work because the column named aliases are not visible throughout the statement.

	select 1 as a, 2 as b, (b-a) as c;

The simplicity of this query is suspicious. The problem is that 1 and 2 are just sitting in for complex expressions or aggregates. The following statement using aggregates does not work either.

	select sum(a) as x, sum(b) as y, (x-y) from ...;

The two techniques to resolve this problem are to either use a subselect or to repeat the expressions.

	select x, y, x-y from (select sum(a) as x, sum(b) as y from ...);
	select sum(a) as x, sum(b) as y, sum(a)-sum(b) as z from ...;

If your expressions are aggregates, the system will recognize that they are repeated in the statement and not be rerun. In the two examples above, sum(a) and sum(b) are each calculated once. If you expressions are not just aggregates, the first technique above is best since the more complex expression may not be recognized as already having been run in the context of the statement.

Contributors: Mark Cave-Ayland m.cave-ayland at, Bruno Wolff III bruno at, John Sidney-Woollett johnsw at, Paul Thomas paul at, Jean-Luc Lachance jllachan at, Tom Lane tgl at
Pass by Value in PlPgSQL
[GENERAL] Using arguments with functions 10-July-2004

This is just a little reminder that you cannot modify parameters passed into plpgsql functions. You will get an ERROR indicating that the argument is a CONSTANT.

CREATE OR REPLACE FUNCTION xget_next (varchar) RETURNS varchar AS'
  var1 alias for $1;
  var1 = chr( (ascii(var1) + 1) );
  return var1;

ohc=> select get_next('a');
ERROR:  "$1" is declared CONSTANT
CONTEXT:  compile of PL/pgSQL function "get_next" near line 5
Instead of modifying the argument, set and return another variable or simply return an expression.
CREATE OR REPLACE FUNCTION xget_next (varchar) RETURNS varchar AS'
  var1 alias for $1;
  return chr( (ascii(var1) + 1) );

Contributors: Robert Fitzpatrick robert at, Oliver Elphick olly at, Tom Lane tgl at
Simple Views
[GENERAL] optimization with limit and order by in a view 13-July-2004

It is standard practice to define views without ORDER BY clauses and without explicit qualifications other than what is necessary for JOINs. This practice enables the users of the view to qualify and order the resulting data independently of the data set.

In one particular instance, a view was defined for a java bean which for some reason needed an order by clause within the view definition.

Subsequent usage of the view with a LIMIT on it showed that the query was very, very slow. The view without the order by in its definition and then was called adding the ORDER BY and LIMIT clauses. Without the ORDER BY in the view definition the query went very fast. The queries looked like this:

CREATE VIEW nt_ordered AS
	SELECT * FROM bigtable bt JOIN littletable lt USING (id)
CREATE VIEW nt_notordered AS
	SELECT * FROM bigtable bt JOIN littletable lt USING (id);

select * from nt_ordered limit 20; --- slow
select * from nt_notordered order by id limit 20; -- fast

On first glance, it would seem that the queries are exactly equivalent. But this is not actually the case. Reviewing the EXPLAIN output showed that the plan chosen by the optimizer first sorted the data set and then applied the LIMIT when the ORDER BY was part of the view definition. When the ORDER BY was not part of the view definition, it chose a different plan to optimize for the LIMIT. That plan did not try to sort the entire data set first.

Contributors: elein at,
Reindex to Recover Index Space
[GENERAL] DELETE TABLE xx do not erase index file after a vacuum 01-July-2004

Deleting rows quickly from a large table can usually be done using TRUNCATE. However, if there are FOREIGN KEYS on the table, you will have to DELETE the rows.

Using DELETE followed by VACUUM FULL will not necessarily recover the space previously used by the indexes on the table. In order to ensure that the index space is recovered, it is recommended that you REINDEX the table.

Contributors: Hervé Piedvache herve at, Tom Lane tgl at

Comments and Corrections are welcome. Suggestions and contributions of items are also welcome. Send them in!
Copyright A. Elein Mustain 2003, 2004, 2005, 2006, 2007, 2008, 2009

Search General Bits & Search WWW