>-Original Message-
>From: pgsql-performance-ow...@postgresql.org
>
>We use a typical counter within a transaction to generate
>order sequence number and update the next sequence number.
>This is a simple next counter - nothing fancy about it. When
>multiple clients are concurrently a
Matthew Wakeling wrote:
> I have implemented the very same algorithm in both a Postgres GiST
> extension and as a standalone Java program. In general, the
> standalone Java program performs about 100 times faster than
> Postgres when running a large index-based nested loop join.
>
> I profiled
Peter Eisentraut writes:
>> Does anyone have any ideas/opinions/statistics on what the performance
>> difference is between the two calling conventions?
> Version 1 is technically slower if you count the number of instructions,
That would be true if you compare version-0-to-version-0 calls (ie,
On Fri, 17 Jul 2009, Peter Eisentraut wrote:
On Friday 17 July 2009 16:40:40 Matthew Wakeling wrote:
I'm considering rewriting a postgres extension (GiST index bioseg) to make
it use version 1 calling conventions rather than version 0.
Does anyone have any ideas/opinions/statistics on what the
On Friday 17 July 2009 16:40:40 Matthew Wakeling wrote:
> I'm considering rewriting a postgres extension (GiST index bioseg) to make
> it use version 1 calling conventions rather than version 0.
>
> Does anyone have any ideas/opinions/statistics on what the performance
> difference is between the t
Scara Maccai wrote:
>> Be sure to include an ORDER BY clause.
> Isn't it going to be much slower?
It might be; you'd have to test to know for sure.
> The important thing is that most of the records are stored "close"
> enough one to the other in the right order.
Then, yeah, it might not
> Be sure to include an ORDER BY clause. For
> example, if someone else starts a query which the planner
> determines
> is best handled with a table scan, and that is still
> running when you
> issue your INSERT/SELECT, your query will join the current
> scan at
> it's point of progress, and "wra
On Thu, 2009-07-16 at 00:11 -0600, Scott Marlowe wrote:
> As others have said, a serial is a good idea, HOWEVER, if you can't
> have gaps in sequences, or each customer needs their own sequence,
> then you get to lock the rows / table / etc that you're mucking with
> to make sure you don't issue t
Scara Maccai wrote:
> - create table mytable as select * from where time
> (this gets all the data of last month ordered in the
> "almost" correct order, because all the single tables were
> clustered)
Be sure to include an ORDER BY clause. Without that, there is no
guarantee that even two
I'm considering rewriting a postgres extension (GiST index bioseg) to make
it use version 1 calling conventions rather than version 0.
Does anyone have any ideas/opinions/statistics on what the performance
difference is between the two calling conventions?
Matthew
--
Patron: "I am looking
Hi all,
>On Wed, Jul 15, 2009 at 10:36 PM, Scott Marlowe
>wrote:
I'd love to see it.
>
> +1 for index organized tables
>
>--Scott
+1 also for me...
I am currently working for a large customer who is migrating his main
application towards PostgreSQL, this application currently using DB2 an
On Wed, Jul 15, 2009 at 2:44 AM, Alex wrote:
> I am using Postgres with Rails. Each rails application "thread" is
> actually a separate process (mongrel) with it's own connection.
>
> Normally, the db connection processes (?) look something like this in
> top:
>
> 15772 postgres 15 0 229m 13m
> As Kevin said, there's no guarantee that tuples will be
> read back
> in the order you inserted them.
Ok, didn't know that
> A better option you might consider is to use a separate
> table for the
> re-ordered tuples.
> You could even do this using partitions
Problem is I'm already using par
13 matches
Mail list logo
