Hi,
I upgraded our master database server from 9.2.2 to 9.2.3 on Monday. We
have been experiencing performance problems since then. Yesterday, our
application hit the connection limit 5 times. It causes approximately
15 seconds of downtime. The database server hit 50 load average, then
everything
On Fri, 08 Mar 2013 20:39:45 +0200, AI Rumman wrote:
Knowing your problem, I read the docs and found that :
*
*
*Fix performance problems with autovacuum truncation in busy workloads
(Jan
Wieck)*
*Truncation of empty pages at the end of a table requires exclusive lock,
but autovacuum was c
2013-03-08 13:27:16 +0200 Emre Hasegeli :
PostgreSQL writes several following logs during the problem which I never
saw before 9.2.3:
LOG: process 4793 acquired ExclusiveLock on extension of relation
305605 of database 16396 after 2348.675 ms
I tried
* to downgrade to 9.2.2
* to disable
On Thu, 14 Mar 2013 06:53:55 +0200, Jeff Janes
wrote:
On Friday, March 8, 2013, Emre Hasegeli wrote:
PostgreSQL writes several following logs during the problem which I never
saw before 9.2.3:
LOG: process 4793 acquired ExclusiveLock on extension of relation
305605
of database 16396
2014-02-12 18:59, Бородин Владимир :
> I have read several topics [1, 2, 3, 4] with similar problems but haven't
> find a good solution. Below is some more diagnostics.
I reported the second one. The diagnostics was very similar to yours.
I think a lot people experienced this problem with big serv
On Thu, Feb 13, 2014 at 11:23 AM, Бородин Владимир wrote:
> Cool. How much ram do you have on your server and what is the size of the
> database?
It has 200 GiB of memory for 100 GB database at that time. We had migrated
the database from MySQL, that was the reason of overmuch resources. I do
not
2014-03-25, Matthew Spilich :
> Has any on the forum seen something similar? Any suggestions on what
> to look at next?If it is helpful to describe the server hardware, it's
> got 2 E5-2670 cpu and 256 GB of ram, and the database is hosted on 1.6TB raid
> 10 local storage (15K 300 GB drives
Pujol Mathieu :
> Hello,
> I already post my question in the General Mailing list, but without
> succeed so I try this one that seems to me more specialized.
> My question is about GIST index.
> I made my own index to handle specific data and operators. It works
> pretty fine but I wonder if it was
> -Original Message-
It is hard to read your message. You should indicate the quoted lines.
Please fix your email client.
> About the contrib/intarray, do I have other choices not using that one?
integer[] and contrib/intarray are two different data types.
> About the join, yeah, in ou
> I'm trying to get a query to run fast enough for interactive use. I've gotten
> some speed-up, but still not there. It is for a tool called IRRExplorer
> (http://irrexplorer.nlnog.net/) that correlates IP routes between Internet
> Route Registries and real-world routing information. We landed on
> Are the coverage operatons just that expensive?
They shouldn't be. A similar query like yours works in 0.5 second on my laptop:
># create table inner_side as select i, ((random() * 255.5)::int::text || '.'
>|| (random() * 255.5)::int::text || '.' || (random() * 255.5)::int::text ||
>'.' || (
> Then there is the mixed IPv6 and IPv4 data that might factor in.
It shouldn't be the problem. The index should separate them on the top level.
> I tried the approach from your benchmark, to try make a more isolated test
> case:
Can you try to isolate it even more by something like this:
sele
> Nothing really interesting here though.
I think the slowdown is not related with the key your searched for,
but the organisation of the index. We have a simple structure for
the index keys. Basically, common bits of the child nodes are stored
on the parent node. It leads to not efficient inde
13 matches
Mail list logo
