Skip site navigation (1) Skip section navigation (2)

Re: "append" takes a lot of time in a query

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Frank Dekervel" <frank(dot)dekervel(at)smartlounge(dot)be>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: "append" takes a lot of time in a query
Date: 2008-05-21 18:44:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
I think you're looking to return set of record or something like that.

On Wed, May 21, 2008 at 4:37 AM, Frank Dekervel
<frank(dot)dekervel(at)smartlounge(dot)be> wrote:
> Hello,
> Small update on this problem:
> Wouter Verhelst came to help debugging, and he determined that the 2 seconds
> were spent planning the query and not executing the query. (executing the
> query is quick as seen in the query plan).
> To avoid replanning this query all the time, Wouter suggest replacing the
> query with a stored procedure (so that the query plan was saved). We did a
> proof of concept, and it seemed to work very well.
> Another approach would be caching of prepared statements, but i found no
> implementations of this on the net.
> We now still need to find a way to hook the stored procs in our O-R mapper:
> generating them the first time a query is done (fairly easy), and
> making "select procname(param1,param2)" behave like a normal query.
> We tried a stored procedure returning a cursor and this seemed to work, but
> we'd like to avoid this as, to use cursors, we need to change the core logic
> of our system that decides whether to use transactions and cursors (now the
> system does not create a cursor if it does not expect too many rows coming
> back and so on, and no transaction if no "update" or "insert" queries have to
> be done).

In response to

pgsql-performance by date

Next:From: H. HallDate: 2008-05-21 19:14:51
Subject: Re: "Big O" notation for postgres?
Previous:From: PFCDate: 2008-05-21 16:27:14
Subject: Re: "Big O" notation for postgres?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group