On Jan 25, 2008 5:50 AM, Tom Lane [EMAIL PROTECTED] wrote:
Hmm. I think what that really means is you haven't got to the part of
the query where the leak is :-(. In my attempt to reproduce this
I found that 8.3 has introduced a memory leak into the RI trigger
support, such that even if an
Hi
I am investigating migrating from postgres 743 to postgres 826 but
although the performance in postgres 826 seems to be generally better
there are some instances where it seems to be markedly worse, a factor
of up to 10. The problem seems to occur when I join to more than 4
tables. Has
Ahh, sorry, I have been too aggressive with my cutting, I am running
8.2.6 and the function is below.
Thanks.
Matthew
CREATE OR REPLACE FUNCTION sp_get_price_panel_id(int4, varchar,
varchar, varchar, bpchar)
RETURNS SETOF t_market_price_panel AS
$BODY$
SELECT *
FROM market mrkt
JOIN
Matthew Lunnon wrote:
I have a query which runs pretty quick ( 0.82ms) but when I put it
inside a stored procedure it takes 10 times as long (11.229ms). Is
this what you would expect and is there any way that I can get around
this time delay?
It depends. You'll need to show us the
Hi ms
I have a query which runs pretty quick ( 0.82ms) but when I put it
inside a stored procedure it takes 10 times as long (11.229ms). Is
this what you would expect and is there any way that I can get around
this time delay?
postgres.conf changes.
shared_buffers = 500MB
work_mem = 10MB
I've posted the patch here:
http://archives.postgresql.org/pgsql-patches/2008-01/msg00123.php
Dean.
_
Get Hotmail on your mobile, text MSN to 63463!
http://mobile.uk.msn.com/pc/mail.aspx
---(end of
Matthew Lunnon [EMAIL PROTECTED] writes:
In this case the query takes 6.037 ms to run on 862 and 2.332 to run on 743.
The difference between 2ms and 6ms is pretty negligable. A single context
switch or disk cache miss could throw the results off by that margin in either
direction.
But what
On Fri, 25 Jan 2008, Simon Riggs wrote:
1. Try to avoid having all the backends hit the queue at once. Instead
of SIGUSR1'ing everybody at the same time, maybe hit only the process
with the oldest message pointer, and have him hit the next oldest after
he's done reading the queue.
My feeling
Scott Marlowe wrote:
Whatever email agent you're using seems to be quoting in a way that
doesn't get along well with gmail, so I'm just gonna chop most of it
rather than have it quoted confusingly... Heck, I woulda chopped a
lot anyway to keep it small. :)
Thanks again for your time. I'm
On Jan 28, 2008 7:54 AM, Alex Hochberger [EMAIL PROTECTED] wrote:
We are trying to optimize our Database server without spending a
fortune on hardware. Here is our current setup.
Main Drive array: 8x 750 GB SATA 2 Drives in a RAID 10 Configuration,
this stores the OS, Applications, and
Hi Scott,
Thanks for your time
Regards
Matthew
Scott Marlowe wrote:
On Jan 28, 2008 5:41 AM, Matthew Lunnon [EMAIL PROTECTED] wrote:
Hi
I am investigating migrating from postgres 743 to postgres 826 but
although the performance in postgres 826 seems to be generally better
there are some
On Jan 28, 2008 5:41 AM, Matthew Lunnon [EMAIL PROTECTED] wrote:
Hi
I am investigating migrating from postgres 743 to postgres 826 but
although the performance in postgres 826 seems to be generally better
there are some instances where it seems to be markedly worse, a factor
of up to 10.
We are trying to optimize our Database server without spending a
fortune on hardware. Here is our current setup.
Main Drive array: 8x 750 GB SATA 2 Drives in a RAID 10 Configuration,
this stores the OS, Applications, and PostgreSQL Data drives. 3 TB
Array, 2 TB Parition for PostgreSQL.
Whatever email agent you're using seems to be quoting in a way that
doesn't get along well with gmail, so I'm just gonna chop most of it
rather than have it quoted confusingly... Heck, I woulda chopped a
lot anyway to keep it small. :)
On Jan 28, 2008 9:27 AM, Matthew Lunnon [EMAIL PROTECTED]
Hi Gregory/All,
Thanks for your time.
Yes the difference is pretty small but does seem to be consistent, the
problem that I have is that this is just part of the query, I have tried
to break things down so that I can see where the time is being spent. I
set the default_statistics_target to
Claire McLister [EMAIL PROTECTED] writes:
When I do an EXPLAIN ANALYZE on one query that returns 3261 rows, it
executes in a reasonable 159ms:
...
If I issue the same query over JDBC or use a PSQL stored procedure, it
takes over 3000 ms, which, of course is unacceptable!
I suspect that
On 28-1-2008 20:25 Christian Nicolaisen wrote:
So, my question is: should I go for the 2.5 disk setup or 3.5 disk
setup, and does the raid setup in either case look correct?
Afaik they are about equal in speed. With the smaller ones being a bit
faster in random access and the larger ones a
Hi All,
I am experiencing a strange performance issue with Postgresql (7.4.19)
+ PostGIS. (I posted to the PostGIS list but got no response, so am
trying here.)
We have a table of entries that contains latitude, longitude values
and I have a simple query to retrieve all entries within a
Hi
We are looking to buy a new server and I am wondering what kind of hardware
we should buy and how to configure it.
We are either getting 8x 2.5 15k rpm sas disks or 6x 3.5 15k rpm sas
disks.
If we go with the 2.5 disks I think we should run 6 disks in raid 10 for
the database and 2 disks in
On Wed, Jan 23, 2008 at 07:29:16PM +0100, Thomas Lozza wrote:
hi
We have an installation of Postgres 8.1.2 (32bit on Solaris 9) with a DB
size of about 250GB on disk. The DB is subject to fair amount of
inserts, deletes and updates per day.
Running VACUUM VERBOSE tells me that I should
On Jan 28, 2008 8:54 AM, Alex Hochberger [EMAIL PROTECTED] wrote:
We are trying to optimize our Database server without spending a
fortune on hardware. Here is our current setup.
Main Drive array: 8x 750 GB SATA 2 Drives in a RAID 10 Configuration,
this stores the OS, Applications, and
On Mon, 28 Jan 2008, Arjen van der Meijden wrote:
On 28-1-2008 20:25 Christian Nicolaisen wrote:
So, my question is: should I go for the 2.5 disk setup or 3.5 disk setup,
and does the raid setup in either case look correct?
Afaik they are about equal in speed. With the smaller ones being a
22 matches
Mail list logo
