oes not exist on system. Does anybody know what I am missing?
Thank you in advance for any help
Kevin Barnard
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not mat
wrote:
Shane Wright <[EMAIL PROTECTED]> writes:
Hmm that gives me an idea, for bulk processing, is there a way of
detecting from a client when a checkpoint is about to happen so it can
wait until it's finished?
No, but maybe you could think about scheduling checkpoints yourself
to not co
ooner or later).
Hmm that gives me an idea, for bulk processing, is there a way of detecting from a client when a checkpoint is about to happen so it can wait until it's finished? Some way that's easier than -z `ps fax | grep post | grep checkpoint` that is ;)
Cheers
Shane
On 3
Hi,
I'm running a reasonable sized (~30Gb) 7.3.4 database on Linux and I'm
getting some weird performance at times.
When the db is under medium-heavy load, it periodically spawns a
'checkpoint subprocess' which runs for between 15 seconds and a minute.
Ok, fair enough, the only problem is the
Hi,
I've used this command to dump just the table concerned, and I get a
zero length file!?! No errors or anything, just a silent exit.
pg_dump -U xx-S xx -F t -a -t tablename mydatabase > ~/backup/mytable
Any ideas? I'm thinking the zero-sized file could be what was causing
the read()s to f
Hi,
I have found, on 7.3.4, a _massive_ performance difference on restoring
without indices - on a 25million row table from 8 hours down to <1
hour!
I've found the best way is to do this... (there may be a script
somewhere that automates this)
- do a --schema-only restore to create the tables
Hi,
fd 0 is usually stdin, unless the program disconnects stdin.
Maybe pg_restore is waiting for input, perhaps a password?
certainly shouldn't be - the table where the problem happens is no
different to any of the others, but I will try doing just that table
later today and see if that makes an
, 4096) = 0
read(0, "", 4096) = 0
read(0, "", 4096) = 0
read(0, "", 4096) = 0
read(0, "", 4096) = 0
read(0, "", 4096) = 0
read(0, ""
, 4096) = 0
read(0, "", 4096) = 0
read(0, "", 4096) = 0
read(0, "", 4096) = 0
read(0, "", 4096) = 0
read(0, "", 4096) = 0
read(0, ""
Hi,
I'm trying to upgrade our 25Gb database from 7.1.3 to 7.3.4 - pg_dump
worked fine, although piping through split to get a set of 1Gb files.
But, after a few attempts on using pg_restore to get the data into the
new installation I'm having a few problems; basically it restores the
first few t
10 matches
Mail list logo