Re: create table in memory

From: Seref Arikan <serefarikan(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Peter Kroon <plakroon(at)gmail(dot)com>, Raghavendra <raghavendra(dot)rao(at)enterprisedb(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: create table in memory
Date: 2012-11-28 23:23:02
Message-ID: CA+4ThdqAhUQ=2FVb_Zf9yNcbPcaXJmSsSORca1SZOKYUcswZvQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks Merlin,
I'll take a better look at CTE.

Best regards
Seref

On Tue, Nov 27, 2012 at 4:48 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

> On Tue, Nov 27, 2012 at 10:06 AM, Seref Arikan <serefarikan(at)gmail(dot)com>
> wrote:
> > I have a function that creates a temp table, inserts rows into it,
> performs
> > joins, and returns a single integer as a result. This is pg 9.1. All
> > sessions are using the exact same temp table structure.
> > re performance requirements: I need this function to return as fast as
> > possible :) On a production server, if the function can complete in
> around
> > 10-20 milliseconds, it would be really good (below 10 ms would be great).
> > The average number of inserted into temp table is around 800, and there
> are
> > about 10 columns in the current design.
>
> Well, one thing to explore is use of CTE. general structure is:
> WITH temp_data AS
> (
> SELECT a_bunch_of_stuff ..
> ),
> modify_something AS
> (
> UPDATE something_else
> FROM temp_data ...
> RETURNING *
> )
> SELECT result_code
> FROM modify_something ...;
>
> There are some pros and cons with this approach vs classic temp table
> generation.
> Pros:
> *) since 9.1 and 'data modifying with' feature, you are not very much
> constrained
> *) dispense with traditional headaches in terms of managing temp tables
> *) very neat and clean
> Cons:
> *) can't build indexes
>
> A hybrid approach, which is more complicated, is to organize a
> permanent table with the current transaction id (via
> txid_current()::text) as the left most part of the primary key.
>
> CREATE TABLE transaction_data
> (
> xid text default txid_current()::text,
> keyfield1 int,
> keyfield2 text,
> [data fields]
> );
>
> This is really fast since the data/indexes are ready to go at all
> time. Your function always inserts, cleanup of stale transaction
> records we can dispense to background process, particularly if you can
> find appropriate time to TRUNCATE the table (which would hiccup
> processes using the table).
>
> merlin
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2012-11-28 23:51:38 Re: Updateable VIEWS and the manual
Previous Message Tom Lane 2012-11-28 23:13:00 Re: pg_listening_channels()