On 2. Oct, 2008, at 10:00, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote:
Unfornatly, i can't update pgsql to 8.3 since it's not in debian
stable.
Did you consider using backport packages (http://www.backports.org) for
Debian Etch? They are providing postgresql v.8.3.3 packages for Debian
E
On 22.04.2008, at 17:25, Scott Marlowe wrote:
On Tue, Apr 22, 2008 at 7:42 AM, Thomas Spreng <[EMAIL PROTECTED]>
wrote:
I think I'll upgrade PostgreSQL to the latest 8.3 version in the next
few days anyway, along with a memory upgrade (from 1.5GB to 4GB)
and a
new 2x RAID-1 (inst
On 19.04.2008, at 19:11, Christopher Browne wrote:
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Thomas
Spreng) wrote:
On 16.04.2008, at 17:42, Chris Browne wrote:
What I meant is if there are no INSERT's or UPDATE's going on it
shouldn't affect SELECT queries
On 19.04.2008, at 19:04, Scott Marlowe wrote:
No, that will certainly NOT just affect write performance; if the
postmaster is busy writing out checkpoints, that will block SELECT
queries that are accessing whatever is being checkpointed.
What I meant is if there are no INSERT's or UPDATE's go
On 17.04.2008, at 14:03, sathiya psql wrote:
Hi,
I need to change the name of the constraint.,
Or i need to drop the constraint, and i need to create constraint
with new
name, how the impact of this in performance, because these constraint
changes am going to do in a table which has 10 mill
On 16.04.2008, at 17:42, Chris Browne wrote:
[EMAIL PROTECTED] (Thomas Spreng) writes:
On 16.04.2008, at 01:24, PFC wrote:
The queries in question (select's) occasionally take up to 5 mins
even if they take ~2-3 sec under "normal" conditions, there are no
sequencial scan
On 16.04.2008, at 01:24, PFC wrote:
The queries in question (select's) occasionally take up to 5 mins
even if they take ~2-3 sec under "normal" conditions, there are no
sequencial scans done in those queries. There are not many users
connected (around 3, maybe) to this database usually si
Hi everyone,
I have some serious performance problems on a database where some
queries take up to 100 (or even more) times longer occasionally. The
database itself consists of one bigger table (around 3.5GB in size and
around 2 mio rows, 4-5 additional indexes) and some really small tables.