when concurrency insert violate the unique constraints , they block each
other , i test this in oracle10g, has the same behavour. I think this
may be reasonable because the uqniue check must be the seriazable
check .
for resolve this problem , i do the unique check in application as
poss
On Tue, Feb 2, 2010 at 5:06 AM, Yeb Havinga wrote:
> I believe it does for (re) binding of parameter values to prepared
> statements, but not in the case of an sql function. To test an idea, there
> might be a workaround where you could write a pl/pgsql function that makes a
> string with the quer
On Thu, 4 Feb 2010, wangyuxiang wrote:
foreign key constraint lock behavour :
The referenced FK row would be added some exclusive lock , following is the
case:
CREATE TABLE tb_a
(
id character varying(255) NOT NULL,
"name" character varying(255),
b_id character varying(255) NOT NULL,
CON
foreign key constraint lock behavour :
The referenced FK row would be added some exclusive lock , following is the
case:
CREATE TABLE tb_a
(
id character varying(255) NOT NULL,
"name" character varying(255),
b_id character varying(255) NOT NULL,
CONSTRAINT tb_a_pkey PRIMARY KEY (id),
On Fri, Jan 29, 2010 at 10:49 PM, Glenn Maynard wrote:
> Hitting a performance issues that I'm not sure how to diagnose.
>
> SELECT highscores_for_steps_and_card(s.id, 591, 1) FROM stomp_steps s;
> Seq Scan on stomp_steps s (cost=0.00..793.52 rows=2902 width=4)
> (actual time=26509.919..26509.919
Rob Lemley wrote:
here was a discussion on the postgres lists about somehow having the
postgres distribution include the functionality to set oom_adj on
startup. To my knowledge, that's not in 8.3 so I wrote a script and
init.d script to do this on Debian systems.
That's not in anything earl
Andy Colson wrote:
> work_mem = 32MB
> maintenance_work_mem = 64MB
if you have lots and lots of connections, you might need to cut these
down?
definitely, work_mem is the main focus.
If I understand correctly, th 64MB maintenance_work_mem is per vacuum
task, and on this system there are 3
Robert Haas wrote:
On Wed, Feb 3, 2010 at 10:10 AM, Amitabh Kant wrote:
work_mem = 160MB # pg_generate_conf wizard 2010-02-03
Overall these settings look sane, but this one looks like an
exception. That is an enormous value for that parameter...
Yeah, I think I need to retune th
On Wed, Feb 3, 2010 at 10:10 AM, Amitabh Kant wrote:
> work_mem = 160MB # pg_generate_conf wizard 2010-02-03
Overall these settings look sane, but this one looks like an
exception. That is an enormous value for that parameter...
...Robert
--
Sent via pgsql-performance mailing list (pgsql-perf
On Tue, Feb 2, 2010 at 3:47 PM, Andy Colson wrote:
>> effective_cache_size = 5000MB
>
> I see your running a 32bit, but with bigmem support, but still, one process
> is limited to 4gig. You'd make better use of all that ram if you switched
> to 64bit. And this cache, I think, would be limited to
Thank you all, You were right on the analyze. Insert statement with an
aggregated subquery had a problem on an empty table.
I had to change the queries to do a simple insert then analyze on the table
followed by an update with an aggregated sub query. That goes thru very fast.
-mridula
From:
On 2/3/2010 11:17 AM, Matt White wrote:
On Feb 2, 1:11 pm, a...@squeakycode.net (Andy Colson) wrote:
On 2/2/2010 1:03 PM, Matt White wrote:
On Feb 2, 6:06 am, Edgardo Portalwrote:
On 2010-02-02, Matt Whitewrote:
I have a relatively straightforward query that by itself isn't tha
On 2/3/2010 9:10 AM, Amitabh Kant wrote:
Hello
I have a server dedicated for Postgres with the following specs:
RAM 16GB, 146GB SAS (15K) x 4 - RAID 10 with BBU, Dual Xeon E5345 @
2.33GHz
OS: FreeBSD 8.0
It runs multiple (approx 10) databases ranging from 500MB to over 24 GB
in size. All of
On 02/03/10 16:10, Amitabh Kant wrote:
Hello
I have a server dedicated for Postgres with the following specs:
RAM 16GB, 146GB SAS (15K) x 4 - RAID 10 with BBU, Dual Xeon E5345 @
2.33GHz
OS: FreeBSD 8.0
If you really do have "heavy read and write" load on the server, nothing
will save you
On Wed, 2010-02-03 at 20:42 +0530, Amitabh Kant wrote:
> Forgot to add that I am using Postgres 8.4.2 from the default ports of
> FreeBSD.
start with this page
http://www.postgresql.org/docs/8.4/static/kernel-resources.html
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresq
2010/2/2 Mridula Mahadevan
> Hi,
>
> I am running a bunch of queries within a function, creating some temp
> tables and populating them. When the data exceeds say, 100k the queries
> start getting really slow and timeout (30 min). when these are run outside
> of a transaction(in auto commit mod
On Tue, Feb 2, 2010 at 7:14 PM, Tom Lane wrote:
> "Davor J." writes:
> > Now, if one takes a subquery for "1", the optimizer evaluates it first
> > (let's say to "1"), but then searches for it (sequentially) in every
> > partition, which, for large partitions, can be very time-consuming and
> go
wyx6...@sina.com wrote:
> after shaming , I think i should pick out some my points:
> the unique constraints actualy kill concurrency write transaction when
> concurrency insert violate the unique constraints , they block each
> other , i test this in oracle10g, has the same behavour. I think this
Hello
I have a server dedicated for Postgres with the following specs:
RAM 16GB, 146GB SAS (15K) x 4 - RAID 10 with BBU, Dual Xeon E5345 @
2.33GHz
OS: FreeBSD 8.0
It runs multiple (approx 10) databases ranging from 500MB to over 24 GB in
size. All of them are of the same structure, and almost
Forgot to add that I am using Postgres 8.4.2 from the default ports of
FreeBSD.
With regards
Amitabh Kant
On Wed, Feb 3, 2010 at 8:40 PM, Amitabh Kant wrote:
> Hello
>
> I have a server dedicated for Postgres with the following specs:
>
> RAM 16GB, 146GB SAS (15K) x 4 - RAID 10 with BBU, Dual
2010/2/2 :
> the unique constraints actualy kill concurrency write transaction when
> concurrency insert violate the unique constraints , they block each other ,
> i test this in oracle10g, has the same behavour. I think this may be
> reasonable because the uqniue check must be the seriazable ch
On 02/03/10 14:42, Robert Haas wrote:
On Wed, Feb 3, 2010 at 6:53 AM, Greg Stark wrote:
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas wrote:
I think you're probably right, but it's not clear what the new name
should be until we have a comment explaining what the function is
responsible for.
S
On Wed, Feb 3, 2010 at 6:53 AM, Greg Stark wrote:
> On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas wrote:
>> I think you're probably right, but it's not clear what the new name
>> should be until we have a comment explaining what the function is
>> responsible for.
>
> So I wrote some comments but w
On 02/03/10 12:53, Greg Stark wrote:
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas wrote:
I think you're probably right, but it's not clear what the new name
should be until we have a comment explaining what the function is
responsible for.
So I wrote some comments but wasn't going to repost th
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas wrote:
> I think you're probably right, but it's not clear what the new name
> should be until we have a comment explaining what the function is
> responsible for.
So I wrote some comments but wasn't going to repost the patch with the
unchanged name wit
On Tue, 2 Feb 2010, Rob wrote:
pg 8.3.9, Debian Etch, 8gb ram, quadcore xeon, megaraid (more details at end)
~240 active databases, 800+ db connections via tcp.
Linux 2.6.18-6-686-bigmem #1 SMP Thu Nov 5 17:30:05 UTC 2009 i686
GNU/Linux (Debian Etch)
8 MB RAM
4 Quad Core Intel(R) Xeon(R) CPU
Tom Lane writes:
> "Davor J." writes:
>> Now, if one takes a subquery for "1", the optimizer evaluates it first
>> (let's say to "1"), but then searches for it (sequentially) in every
>> partition, which, for large partitions, can be very time-consuming and goes
>> beyond the point of partitio
2010/2/1 :
> * joke 1: insert operation would use a excluse lock on reference row by the
> foreign key . a big big big performance killer , i think this is a stupid
> design .
>
> * joke 2: concurrency update on same row would lead to that other
> transaction must wait the earlier transaction comp
28 matches
Mail list logo
