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
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 ||
'.' ||
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
-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 our
Pujol Mathieu mathieu.pu...@realfusio.com:
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
2014-03-25, Matthew Spilich mspil...@tripadvisor.com:
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
2014-02-12 18:59, Бородин Владимир r...@simply.name:
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
On Thu, Feb 13, 2014 at 11:23 AM, Бородин Владимир r...@simply.name 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
On Thu, 14 Mar 2013 06:53:55 +0200, Jeff Janes jeff.ja...@gmail.com
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
2013-03-08 13:27:16 +0200 Emre Hasegeli emre.haseg...@tart.com.tr:
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
On Fri, 08 Mar 2013 20:39:45 +0200, AI Rumman rumman...@gmail.com 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,
11 matches
Mail list logo
