On Wednesday 29 October 2003 2:23 pm, Tom Lane wrote:
> Your initial message stated plainly that the problem was in INSERTs;
> it's not surprising that you got unhelpful advice.
But perhaps my use of the term "insert" to describe upload was a very bad call
given the domain of the list...
I assu
Damien Dougan <[EMAIL PROTECTED]> writes:
> Now, our problem seems to be the delays introduced by reading from the
> public views.
Your initial message stated plainly that the problem was in INSERTs;
it's not surprising that you got unhelpful advice.
> View definition:
> [ huge view full of LEFT
On Monday 27 October 2003 8:12 pm, Tom Lane wrote:
> Damien Dougan <[EMAIL PROTECTED]> writes:
> > Has anyone any ideas as to what could be causing the spiraling
> > performance?
>
> You really haven't provided any information that would allow anything
> but guesses, but I'll guess anyway: poor pla
> "GS" == Greg Stark <[EMAIL PROTECTED]> writes:
GS> At a guess the foreign key relationships you're enforcing don't
GS> have indexes to help them. If they do perhaps postgres isn't using
GS> them.
Or, if you do have indexes, they've bloated to be way too big and are
overwhelming your shared
Damien Dougan <[EMAIL PROTECTED]> writes:
> Has anyone any ideas as to what could be causing the spiraling performance?
You really haven't provided any information that would allow anything
but guesses, but I'll guess anyway: poor plans for foreign key checks?
See nearby threads.
Damien Dougan <[EMAIL PROTECTED]> writes:
> Our batch upload is performing a number of stored procedures to insert data on
> the database. Initially, this results in quite good performance, but rapidly
> spirals down to approximately 1 per second after some minutes.
It's fairly unlikely anyone
Hi All,
We've been experiencing extremely poor batch upload performance on our
Postgres 7.3 (and 7.3.4) database, and I've not been able to improve matters
significantly using any suggestions I've gleamed off the mailing list
archives ... so I was wondering if anyone with a bigger brain in this