Hi All,
I've recently run into problems with my kernel complaining that I ran
out of memory, thus killing off postgres and bringing my app to a
grinding halt.
I'm on a 32-bit architecture with 16GB of RAM, under Gentoo Linux.
Naturally, I have to set my shmmax to 2GB because the kernel
Hi,
I've discovered a peculiarity with using btrim in an index and was
wondering if anyone has any input.
My table is like this:
Table public.m_object_paper
Column| Type | Modifiers
On Dec 9, 2008, at 3:27 PM, Tom Lane wrote:
Richard Yen [EMAIL PROTECTED] writes:
I've discovered a peculiarity with using btrim in an index and was
wondering if anyone has any input.
What PG version is this?
This is running on 8.3.3
In particular, I'm wondering if it's one of the early
On Dec 10, 2008, at 11:34 AM, Tom Lane wrote:
Richard Yen [EMAIL PROTECTED] writes:
You guys are right. I tried Miller and gave me the same result.
Is
there any way to tune this so that for the common last names, the
query run time doesn't jump from 1s to 300s?
If the planner's
On Dec 10, 2008, at 11:39 AM, Robert Haas wrote:
You guys are right. I tried Miller and gave me the same result.
Is there
any way to tune this so that for the common last names, the query
run time
doesn't jump from 1s to 300s?
Thanks for the help!
Can you send the output of EXPLAIN
On Dec 10, 2008, at 4:08 PM, Tom Lane wrote:
Richard Yen [EMAIL PROTECTED] writes:
Is there any way to tune this so that for the common last names,
the query
run time doesn't jump from 1s to 300s?
Well, as near as I can tell there's factor of a couple hundred
difference between
Hi All,
Not sure if this is the right pgsql-* channel to post to, but I was
hoping maybe someone could answer a question from one of my fellow
developers. Please read below:
So, following the documentation, we wrote a little ASYNC version of
exec. here is the code:
PGresult
Hi All,
I encountered an odd issue regarding check constraints complaining
when they're not really violated.
For this particular machine, I am running 8.3.7, but on a machine
running 8.3.5, it seems to have succeeded. I also upgraded a third
machine from 8.3.5 to 8.3.7, and the query
Hello,
Wondering what's a good value for effective_io_concurrency when dealing with
FusionIO drives...anyone have any experience with this?
I know that SSDs vary from 10 channels to 30, and that 1 SSD about as fast as a
4-drive RAID, but I can't seem to settle on a good value to use for
Hi everyone,
We've recently encountered some swapping issues on our CentOS 64GB Nehalem
machine, running postgres 8.4.2. Unfortunately, I was foolish enough to set
shared_buffers to 40GB. I was wondering if anyone would have any insight into
why the swapping suddenly starts, but never
On Mar 26, 2010, at 5:25 PM, Scott Carey wrote:
Linux until recently does not account for shared memory properly in its swap
'aggressiveness' decisions.
Setting shared_buffers larger than 35% is asking for trouble.
You could try adjusting the 'swappiness' setting on the fly and seeing how
Kind of off-topic, but I've found that putting the history table on a separate
spindle (using a separate tablespace) also helps improve performance.
--Richard
On Apr 8, 2010, at 12:44 PM, Robert Haas wrote:
2010/4/8 Merlin Moncure mmonc...@gmail.com:
previous to 8.2, to get good
Hi everyone,
I use DBD::Pg to interface with our 8.4.2 database, but for a particular query,
performance is horrible. I'm assuming that the behavior of $dbh-prepare is as
if I did PREPARE foo AS (query), so I did an explain analyze in the commandline:
db_alpha=# prepare foo6 as (SELECT me.id,
Hi everyone,
I'm running 8.4.2 on a CentOS machine, and postgres recently died with signal 6
because the pg_xlog partition filled up (33GB) on 7/4/10 10:34:23 (perfect
timing, as I was hiking in the mountains in the remotest parts of our country).
I did some digging and found the following:
Sorry, I forgot to mention that archive_mode is off and commented out, and
archive command is '' and commented out.
Thanks for following up!
-- Richard
On Jul 7, 2010, at 1:58, Mark Kirkwood mark.kirkw...@catalyst.net.nz wrote:
On 07/07/10 13:10, Richard Yen wrote:
This leads me
On Jul 6, 2010, at 8:25 PM, Scott Marlowe wrote:
Tell us what you can about your hardware setup.
Sorry, I made the bad assumption that the hardware setup would be
irrelevant--dunno why I thought that.
My hardware setup is 2 FusionIO 160GB drives in a RAID-1 configuration, running
on an HP
On Jul 8, 2010, at 12:04 PM, Kevin Grittner wrote:
Robert Haas robertmh...@gmail.com wrote:
I don't understand how you managed to fill up 37GB of disk with
WAL files. Every time you fill up checkpoint_segments * 16MB of
WAL files, you ought to get a checkpoint. When it's complete, WAL
On Jul 8, 2010, at 12:27 PM, Tom Lane wrote:
(Hmm ... but those complaints are logged at level WARNING, which as
discussed elsewhere is really lower than LOG. Should we change them?)
Hmm, I did a grep on WARNING on my log, and the only thing that turns up are
the WARNING: terminating
On Jul 8, 2010, at 12:50 PM, Tom Lane wrote:
Richard Yen rich...@iparadigms.com writes:
My concern is that--as in the original post--there were moments where 129
WAL files were generated in one minute. Is it plausible that this
autovacuum could be responsible for this?
That's
On Jul 8, 2010, at 12:50 PM, Kevin Grittner wrote:
Richard Yen rich...@iparadigms.com wrote:
there were moments where 129 WAL files were generated in one
minute. Is it plausible that this autovacuum could be responsible
for this?
I don't remember seeing your autovacuum and vacuum
Hi Everyone,
I recently saw a crash on one of our databases, and I was wondering if this
might be an indication of something with WAL that might be unexpectedly
creating more files than it needs to?
Nov 5 16:18:27 localhost postgres[25092]: [111-1] 2011-11-05 16:18:27.524
PDT [user=slony,db=uk
21 matches
Mail list logo
