Re: [SQL] Slow Inserts Again

Is it at all possible that the optimizer is responsible for this behaviour?
The reason I ask is that the fact that when the inserts start the optimizer is
working with a very small table, as the table grows larger the optimizer never
learns it because no VACUUM or VACUUM ANALYZE have been run.

If this is indeed the problem, then running VACUUM after every 10,000 inserts
would solve the problem.

Just curious what you folks think.

Rudy

On 3 May 99, at 12:19, Bruce Momjian wrote:

> > >> Why _each_?
> > >> Enclose ALL statements by begin; & end; to insert ALL data
> > >> in SINGLE transaction:
> >
> > But the transaction boundaries wouldn't have anything to do with
> > Frank's real problem, which is that the insertions are getting
> > slower and slower. There's no good reason for that; and other
> > people are not reporting any comparable problems. (Considering
> > that we *have* been getting trouble reports for more-than-2-gig
> > tables, it's clear that people are putting large amounts of data
> > into 6.5; so it's not like Frank is stressing the system more
> > than it has been before.)
> >
> > Frank, what does the memory usage of the backend that's processing
> > this insertion look like; has it been growing steadily? I'm wondering
> > whether you could have a problem with poor malloc behavior, or some
> > such.
>
> Yes, memory use it the place to look. We have had bugs in the past that
> did not free memory, causing this problem.
>
> --
> Bruce Momjian | http://www.op.net/~candle
> maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>
>