"Craig A. James" <[EMAIL PROTECTED]> writes:
> Thanks to both for your answers. But no -- It's for new posts. In fact,
> when writing the email that started this thread, it was only to
> pgsql-performance@postgresql.org (I double-checked by using emacs on my
> Thunderbird "Sent" folder), yet I
"Steve McWilliams" <[EMAIL PROTECTED]> writes:
> I notice that non-printables in bytea values are being spit out by pg_dump
> using escaped octet sequences even when the "-Fc" option is present
> specifying use of the custom binary output format rather than plain text
> format. This bloats the siz
On Wed, Jul 12, 2006 at 15:41:14 -0500,
Medora Schauer <[EMAIL PROTECTED]> wrote:
> I have just upgraded from 7.3.4 to 8.1.4 and now *all* db access calls
> are extremely slow. I didn't need to preserve any old data so at this
> point all my tables are empty. Just connecting to a db takes sever
> >This is an automatically generated Delivery Status Notification.
> >Delivery to the following recipients failed.
> > [EMAIL PROTECTED]
yes, I got the same thing that you did here. only i got when I replied all to
your email. Are you
sure this individual wasn't listed in any of y
I wrote:
I can't find an address to complain about the mailing list itself, so
apologies but I'm posting directly to this list. Every time I post to
this group, I get returned mails about OTHER subscribers' invalid
accounts, like the one below.
Michael Glaesemann replied:
Is this when you're
On Wednesday 12 July 2006 13:41, Medora Schauer wrote:
> I have just upgraded from 7.3.4 to 8.1.4 and now *all* db access calls
> are extremely slow. I didn't need to preserve any old data so at this
> point all my tables are empty. Just connecting to a db takes several
> seconds.
>
>
>
> When I
> I can't find an address to complain about the mailing list itself, so
> apologies but I'm posting
> directly to this list. Every time I post to this group, I get returned mails
> about OTHER
> subscribers' invalid accounts, like the one below. What's up? This seems to
> be a new
> phenomeno
I have just upgraded from 7.3.4 to 8.1.4 and now *all* db access calls are extremely slow. I
didn’t need to preserve any old data so at this point all my tables are
empty. Just connecting to a db takes several seconds.
When I was accidentally linking my app with the 7.3.4 libs
but run
On Wed, 12 Jul 2006, Neil Hepworth wrote:
Yes, it was the same DB so, yes 8.1 gives roughly a four fold improvement
(assuming hardware and OS differences aren't that significant - I'd expect
the Linux version to be faster if anything); which certainly ain't bad! :)
Good idea for the vacuumdb -a
On Wed, Jul 12, 2006 at 10:16:40 -0600,
"Koth, Christian (DWBI)" <[EMAIL PROTECTED]> wrote:
>
> I have noticed a strange performance behaviour using a commit statement on
> two different machines. On one of the machines the commit is many times
> faster than on the other machine which has fast
On Jul 12, 2006, at 11:39 , Craig A. James wrote:
I can't find an address to complain about the mailing list itself,
so apologies but I'm posting directly to this list. Every time I
post to this group, I get returned mails about OTHER subscribers'
invalid accounts, like the one below.
I
Craig A. James wrote:
> Magnus Hagander wrote:
>>> This raises the question: Why doesn't Postgres have a "kill session"
>>> command that works? Oracle has it, and it's invaluable; there is no
>>> substitute. Various writers to these PG lists have raised the
>>> question repeatedly. Is it just a
I can't find an address to complain about the mailing list itself, so apologies
but I'm posting directly to this list. Every time I post to this group, I get
returned mails about OTHER subscribers' invalid accounts, like the one below.
What's up? This seems to be a new phenomenon. Should th
On Wednesday 12 July 2006 09:16, Koth, Christian (DWBI) wrote:
> Hi,
>
> please help me with the following problem:
>
> I have noticed a strange performance behaviour using a commit statement on
> two different machines. On one of the machines the commit is many times
> faster than on the other mac
I notice that non-printables in bytea values are being spit out by pg_dump
using escaped octet sequences even when the "-Fc" option is present
specifying use of the custom binary output format rather than plain text
format. This bloats the size of bytea values in the dump file by a factor
of 3+ ty
> > I beleive the function to kill a backend is actually in the
> codebase,
> > it's just commented out because it's considered dangerous.
> There are
> > some possible issues (see -hackers archives) about sending SIGTERM
> > without actually shutting down the whole cluster.
> >
> > Doing the
On Wed, 12 Jul 2006 10:16:40 -0600
"Koth, Christian (DWBI)" <[EMAIL PROTECTED]> wrote:
> I have noticed a strange performance behaviour using a commit statement on
> two different machines. On one of the machines the commit is many times
> faster than on the other machine which has faster hardwar
The IDE drive is almost certainly lying about flushing data to the disk.
Lower-end consumer drives often do.
What this means is that commits will be a whole lot faster, but the
database loses its ACID guarantees, because a power failure at the wrong
moment could corrupt the whole database.
If you
On Wed, Jul 12, 2006 at 08:43:18AM -0700, Craig A. James wrote:
>> Then you killed the wrong backend...
>> No queries run in postmaster. They all run in postgres backends. The
>> postmaster does very little actual work, other than keeping track of
>> everybody else.
>
> It turns out I was confused
Hi,
please help me with the following problem:
I have noticed a strange performance behaviour using a commit statement on two
different machines. On one of the machines the commit is many times faster than
on the other machine which has faster hardware. Server and client are running
always on
Magnus Hagander wrote:
This raises the question: Why doesn't Postgres have a "kill
session" command that works? Oracle has it, and it's
invaluable; there is no substitute. Various writers to these
PG lists have raised the question repeatedly. Is it just a
matter that nobody has had the time
Please Cc: the list when replying to things like this so everyone can see (and
likely help).
I'm not sure what you're response is actually regarding. Could you give some
more detail?
On Wed, 12 Jul 2006, Rizal wrote:
so, i must upgrade my PostgreSQL 803 which i have with a new version ?
-
On Wednesday 12 July 2006 01:33, Thomas Radnetter wrote:
> Hello!
>
> We're facing a performance problem here in a Oracle 10g -> PostgreSQL
> environment. The Oracle DB accesses the PostgreSQL DB via UnixODBC +
> psqlODBC.
>
> There are some 100 records on the Oracle DB to be updated with data
> ob
Thomas,
On 7/12/06, Thomas Radnetter <[EMAIL PROTECTED]> wrote:
Is this the correct place to issue this problem?
It is if your issue is due to a PostgreSQL performance problem.
How can I trace down the cause for this performance problem?
The first thing to do is to determine if it is a pro
Hello!We're facing a performance problem here in a Oracle 10g -> PostgreSQL environment. The Oracle DB accesses the PostgreSQL DB via UnixODBC + psqlODBC.There are some 100 records on the Oracle DB to be updated with data obtained from a view of the PostgreSQL DB. The fe
Hello Everyone,
I'm trying to find out/understand what causes my 'out of memory' error.
I do not have enough experience with such logs to understand what is
wrong or how to fix it. So i hope someone can point me in the right
direction.
The 'rpt.rpt_verrichting' table contains about 8.5 milli
26 matches
Mail list logo
