On 15.10.2012 17:01, Craig James wrote:
On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani
wrote:
> I've googled a bit and I've found a way to disable hyperthreading
> without
> the need to reboot the system and entering the bios:
>
> echo 0 >/sys/devices/system/node/no
Hi,
On 03.09.2011 09:26, Gerhard Wohlgenannt wrote:
Activating log_min_duration shows for instance this query --- there are
now constantly queries which take absurdely long.
2 things you should check:
- if your /var/lib/postgresql is on an ext3 fs, I've seen such things
before due to the cha
On Wed, 29 Jun 2011 13:55:58 +0200, Svetlin Manavski
wrote:
Question: Is there a way to get the same result from within a PL/pgSQL
function but running all the sub-queries in parallel? In case it is not
directly available, which one would be the simplest way to implement it
in
my applicati
Am 19.04.2011 11:15, schrieb Laurent Laborde:
Soft RAID1 (md)
ext3
We have experimented a bit with Postgres and ext3 (with and without Linux
software RAID1) and have found that since somewhere after 2.6.18, it has been
prohibitively slow and causing high latencies during buffer flushes. You w
Hi,
we are seeing latency spikes in the 2-3 second range (sometimes 8-10s) for
queries that usually take 3-4ms on our systems and I am running out of things to
try to get rid of them. Perhaps someone here has more ideas - here's a
description of the systems and what I've tried with no impact a
Marinos Yannikos wrote:
(what exactly does ANALYZE look at for text columns? in our case, about
7% of the rows match the index condition, so it seems that left-anchored
regexp/like matches are not evaluated using the gathered
most-common-value list at all)
oops, I think I gave myself the
It seems that ANALYZE does not really sample text column values as much
as it could. We have some very bad query plans resulting from this:
...
-> Bitmap Index Scan on m_pkey (cost=0.00..28.61 rows=102
width=0) (actual time=171.824..171.824 rows=683923 loops=1)
Index
Heikki Linnakangas wrote:
Lists wrote:
Server is a dual core xeon 3GB ram and 2 mirrors of 15k SAS drives (1
for most data, 1 for wal and a few tables and indexes)
In total all databases on the server are about 10G on disk (about 2GB
in pgdump format).
I'd suggest buying as much RAM as you
We have a few slow queries that use sequential scans on tables that have
plenty of indexes (for other queries), on a box with a lot of RAM and 13
active cores (don't ask), so I was curious to find out how to put this
environment to better use. The result is (maybe) interesting, esp. since
Postg
Greg Smith schrieb:
You also didn't mention what disk controller you have, or how much write
cache it has (if any).
8.3.1, Controller is
http://www.infortrend.com/main/2_product/es_a08(12)f-g2422.asp with 2GB
cache (writeback was enabled).
That's almost turning the background writer off. I
Hi,
to save some people a headache or two: I believe we just solved our
performance problem in the following scenario:
- Linux 2.6.24.4
- lots of RAM (32GB)
- enough CPU power (4 cores)
- disks with relatively slow random writes (SATA RAID-5 / 7 disks, 128K
stripe, ext2)
Our database is aro
A. Kretschmer schrieb:
create index foo1 on bla (a);
create index foo2 on bla (b);
create index foo3 on bla (a,b);
[...]
Which version do you have? Since 8.1 pg can use a so called 'bitmap
index scan', because of this feature i guess you don't need the index
foo3. (if you have 8.1 or higher)
Hello,
we have several indexes such as:
create index foo1 on bla (a);
create index foo2 on bla (b);
create index foo3 on bla (a,b);
They are all used often by frequently used queries (according to
pg_statio_user_indexes), but we need somewhat higher INSERT/UPDATE
performance (having tuned mos
Hello,
we're looking into the reason why we are getting warnings about
transaction ID wraparound despite a daily "vaccumdb -qaz". Someone is
claiming that VACUUM without FULL cannot reassign XIDs properly when
max_fsm_pages was set too low (it says so here too, but this is rather
old: http://
Alex Turner wrote:
No offense to that review, but it was really wasn't that good, and
drew bad conclusions from the data. I posted it originaly and
immediately regretted it.
See http://www.tweakers.net/reviews/557/18
Amazingly the controller with 1Gig cache manages a write throughput of
750MB/sec
Joshua D. Drake wrote:
Well I have never even heard of it. 3ware is the defacto authority of
reasonable SATA RAID.
no! 3ware was rather early in this business, but there are plenty of
(IMHO, and some other people's opinion) better alternatives available.
3ware has good Linux drivers, but the pe
Oleg Bartunov schrieb:
Marinos,
what if you construct "apachebench & Co" free script and see if
the issue still exists. There are could be many issues doesn't
connected to postgresql and tsearch2.
Some more things I tried:
- data directory on ramdisk (tmpfs) - no effect
- database connections eith
17 matches
Mail list logo
