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
>
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() |