On Mar 4, 2008, at 6:54 PM, dforums wrote:
Hello,
After controling the settings I so, that shared_buffers is
configurated at 1024 (the default), however, in my postgresql.conf I
set it to 25, is it due to shared memory settings, should I
increase shmmax?
Did you do a full restart o
On Wed, Mar 05, 2008 at 12:15:25AM +, dforums wrote:
> In regards of update, I have around 1 updates while a laps of 10 minutes
>
> Is there a settings to optimise updates ?
If you can, batch them into a single transaction.
If you can, upgrade to 8.3. HOT might help you here.
/* Steinar
Hello,
After controling the settings I so, that shared_buffers is configurated
at 1024 (the default), however, in my postgresql.conf I set it to
25, is it due to shared memory settings, should I increase shmmax?
regards
david
Greg Smith a écrit :
On Tue, 4 Mar 2008, dforums wrote:
ma
Thanks i'm trying with this new settings. I gain only 3 second (2:40 vs
2:37 min) on a treatment of 1000 lines, with it's done every 2 minutes.
For the database version, i'm under postgresql 8.1.11. x64
As i'm in a procedure it seems that postgresql explain analyse doesn't
give details.
I s
On Tue, 4 Mar 2008, dforums wrote:
max_connections = 256
shared_buffers = 1500 # min 16 or max_connections*2, 8KB each
work_mem = 22000# min 64, size in KB
effective_cache_size = 2048 # typically 8KB each
Well, you're giving the main databa
In regards of update, I have around 1 updates while a laps of 10 minutes
Is there a settings to optimise updates ?
regards
david
Alan Hodgson a écrit :
On Tuesday 04 March 2008, dforums <[EMAIL PROTECTED]> wrote:
Hello
We hace a Quad Xeon server, with 8GO of ram, sata II 750Go
I s
tX for your reply,
I do not have more information on disk speed. I'll get it latter.
But My most fear is that for now the database is only of 10 Go.
But I will have to increase it 10 times during the next six month I'm
afraid that these problems will increase.
Regards
David
Alan Hodgson a
On Tuesday 04 March 2008, dforums <[EMAIL PROTECTED]> wrote:
> Hello
>
>
> We hace a Quad Xeon server, with 8GO of ram, sata II 750Go
>
>
> I suppose the main problem is from database server settings.
No, the problem is your hard drive is too slow. One drive can only do maybe
150 seeks per sec
Hello
We hace a Quad Xeon server, with 8GO of ram, sata II 750Go
An postgresql database, of 10 Go
I have several treatment every 2 minutes who select, insert, update
thousand of data in a table. It take a lot of time (0.3300 ms per line)
just to check if a string of 15 char is present, and
On 3/4/08, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> > On Tue, Mar 4, 2008 at 8:42 AM, in message
> > <[EMAIL PROTECTED]>, Chris Kratz
> > <[EMAIL PROTECTED]> wrote:
> >> So, I've now been asked to ping the list as to whether turning off
> >> nested loo
On 3/4/08, Kevin Grittner <[EMAIL PROTECTED]> wrote:
>
> >>> On Tue, Mar 4, 2008 at 8:42 AM, in message
> > Any other thoughts or suggestions?
>
>
> Make sure your effective_cache_size is properly configured.
>
> Increase random_page_cost and/or decrease seq_page_cost.
> You can play with the cost
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> On Tue, Mar 4, 2008 at 8:42 AM, in message
> <[EMAIL PROTECTED]>, Chris Kratz
> <[EMAIL PROTECTED]> wrote:
>> So, I've now been asked to ping the list as to whether turning off
>> nested loops system wide is a bad idea, and why or why not.
> In o
On Tue, 4 Mar 2008, Ivan Voras wrote:
I'm curious about the math behind this - is ~4000 burst or sustained
rate?
Average, which is not quite burst or sustained. No math behind it, just
looking at a few samples of pgbench data on similar hardware. A system
like this one is profiled at
http
>>> On Tue, Mar 4, 2008 at 8:42 AM, in message
<[EMAIL PROTECTED]>, Chris Kratz
<[EMAIL PROTECTED]> wrote:
> So, I've now been asked to ping the list as to whether turning off
> nested loops system wide is a bad idea, and why or why not.
In our environment, the fastest plan for a lot of que
Hi
We are thinking of running a PostgreSQL instance on a virtual host under
Xen.
Any thoughts for/against running PostgreSQL on a virtual host would be
much appreciated.
--
Regards
Theo
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your Subsc
Ivan Voras wrote:
Joshua D. Drake wrote:
This scares me... You lose WAL you are a goner. Combine your OS and
WAL into a RAID 1.
Can someone elaborate on this? From the WAL concept and documentation at
http://www.postgresql.org/docs/8.3/interactive/wal-intro.html I'd say
the only data that sho
Hello Everyone,
I had posted an issue previously that we've been unable to resolve.
An early mis-estimation in one or more subqueries causes the remainder
of the query to choose nested loops instead of a more efficient method
and runs very slowly (CPU Bound). I don't think there is any wa
On Tue, 4 Mar 2008, Ivan Voras wrote:
I'm curious about the math behind this - is ~4000 burst or sustained
rate? For common BBU cache sizes (256M, 512M), filling that amount with
data is pretty trivial. When the cache is full, new data can enter the
cache only at a rate at which old data is evacu
Greg Smith wrote:
> On Mon, 3 Mar 2008, alan bryan wrote:
>
>>> pgbench -c 100 -t 1000 testdb
>> tps = 558.013714 (excluding connections establishing)
>>
>> Just for testing, I tried turning off fsync and got:
>> tps = 4061.662041 (excluding connections establishing)
>
> This is odd. ~500 is wha
Rafael Martinez wrote:
> CPU 50% idle, rest mainly used in "system". Virtually no IO. No
> blocked processes. An impressive amount of context switches. No swap.
>
> An strace(1) of the postgres process may give a hint about the "system"
> part; this is what it does over and over and over agai
alan bryan wrote:
> File './Bonnie.2551', size: 104857600
> Writing with putc()...done
> Rewriting...done
> Writing intelligently...done
> Reading with getc()...done
> Reading intelligently...done
> Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
> ---Sequential
Joshua D. Drake wrote:
> This scares me... You lose WAL you are a goner. Combine your OS and
> WAL into a RAID 1.
Can someone elaborate on this? From the WAL concept and documentation at
http://www.postgresql.org/docs/8.3/interactive/wal-intro.html I'd say
the only data that should be lost are th
On Tue, 4 Mar 2008, alan bryan wrote:
There seems to be something really wrong with disk performance. Here's
the results from bonnie
So input speed is reasonable but write throughput is miserable--<10MB/s.
I'd suggest taking this to one of the FreeBSD lists; this doesn't look
like a Postgre
On Mon, Mar 3, 2008 at 5:11 PM, Greg Smith <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Mar 2008, alan bryan wrote:
>
> >> pgbench -c 100 -t 1000 testdb
>
> > tps = 558.013714 (excluding connections establishing)
> >
> > Just for testing, I tried turning off fsync and got:
>
> > tps = 4061.662041 (exc
Tom Lane wrote:
> Rafael Martinez <[EMAIL PROTECTED]> writes:
>
>> Any ideas why it is taking 2462558.813 ms to finish when the total time
>> for the deletion is 2.546 ms + 3.422 ms + 0.603ms?
>
Hei Tom, I got this information from my colleague:
> Is the problem repeatable?
Repeatable as in
25 matches
Mail list logo
