Hi guys,
Why would an INSERT ever be really slow? This is what I see a lot of in
our site logs:
Dec 5 15:57:48 marshall postgres[19599]: [3-1] LOG: duration:
13265.492 ms statement: INSERT INTO users_sessions (sid, cobrand_id,
uid) VALUES ('145982ac39e1d09fec99cc8a606155e7', '1', '0')
13 s
Volger,
> Since our current Postgres server, a quad Xeon system, finally can't keep
> up with our load anymore we're ready to take the next step.
There are a lot of reasons this could be happening; Quad Xeon is a problematic
platform, the more so if you're on Dell hardware.
I've run PostgreSQL
Thanks for the quick reply, Josh. Here are some more, with wider tables and
'EXPLAIN ANALYZE' output. These tests use the same basic structure as
before, but with 20 data columns rather than just the one:
CREATE TABLE one_big_foo (
partition INTEGER,
bar1 INTEGER,
.
First off, WOO-HOO! The lists are back and I can finally get my PG
fix!!! Now, on to the business at hand...
I have four query plans below, the first two help explain my question,
and the last two are about a speculative alternative. The first query
use a subselects that are generated from a mi
Stacy,
> Each set of test tables holds 1,000,000 tuples with a partition value of
> '1', and 1,000,000 with a partition value of '2'. The bar* columns are all
> set to non-null values. The 'one_big_foo' table stores all 2M rows in one
> table. 'super_foo' and 'union_foo' split the data into two
On Fri, 10 Dec 2004, Tomas [iso-8859-1] Skäre wrote:
> I have a table that looks like this:
>
> Table "public.cjm_object"
> Column | Type| Modifiers
> ---+---+---
> timestamp | bigint| not null
> jobid | bigint
