Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
That works, I tried ctrl-c various ways including from within \i copy.
Problem solved!
Good. I've applied the patch in both HEAD and 8.0 branches.
Since we're very nearly ready to wrap 8.1, would someone with access to
a
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> That works, I tried ctrl-c various ways including from within \i copy.
> Problem solved!
Good. I've applied the patch in both HEAD and 8.0 branches.
Since we're very nearly ready to wrap 8.1, would someone with access to
a Windows machine please dou
> void
> setup_cancel_handler(void)
> {
> + static bool done = false;
> +
> + if (!done)
> SetConsoleCtrlHandler(consoleHandler, TRUE);
> + done = true;
> }
>
That works, I tried ctrl-c various ways including from within \i copy.
Problem solved!
Merlin
--
Zeugswetter Andreas SB SD <[EMAIL PROTECTED]> wrote:
> > What could you recommend? Locking the table and selecting
> > max(invoice_id) wouldn't really be much faster, with max(invoice_id)
> > not using an index...
>
> select invoice_id from table order by invoice_id desc limit 1;
>
> should get y
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> So inserting an invoice would also do an update on a single row
> of the cs_sequence table, which cause the problems.
> Now, with a normal sequence, it works like a charm.
> 17 sec. for 1 rows and 2-3 sec. for commit.
> But why is performance s
> What could you recommend? Locking the table and selecting
> max(invoice_id) wouldn't really be much faster, with max(invoice_id)
> not using an index...
select invoice_id from table order by invoice_id desc limit 1;
should get you the maximum fast if you have a unique index on invoice_id.
An
On 26 Sep 2002 at 12:28, Michael Paesold wrote:
> But why is performance so much degrading? After 1 updates
> on a row, the row seems to be unusable without vacuum! I hope
> the currently discussed autovacuum daemon will help in such a
> situation.
Let mw know if it works. Use CVS BTW.. I am
Tom Lane wrote:
> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > Only vacuum will reset the insert times to the lowest possible!
> > What does the vacuum code do?? :-]
>
> It removes dead tuples. Dead tuples can only arise from update or
> delete operations ... so you have not been telling u
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> Only vacuum will reset the insert times to the lowest possible!
> What does the vacuum code do?? :-]
It removes dead tuples. Dead tuples can only arise from update or
delete operations ... so you have not been telling us the whole
truth. An insert
> Only vacuum will reset the insert times to the lowest possible!
> What does the vacuum code do?? :-]
Please see the manual and the extensive discussions on this point in the
archives. This behaviour is well known -- though undesirable. It is an
effect of the multi-version concurrency control sy
Update:
> vacuum full; vacuum analyze;
> select bench_invoice(1000); select bench_invoice(1000); ... (10 times)
>
> It seems performance is degrading with every insert!
> Here is the result (time in seconds in bench_invoice(), commit between
> selects just under a second)
>
> 13, 24, 36, 47, 58,
Tom Lane wrote:
> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > To insert another 10562 rows takes about 12 minutes now!!!
>
> > As I said I wrote a function to insert the rows (PL/pgSQL). All values
were
> > inserted inside a single function call; I always though that a function
call
> > wo
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> To insert another 10562 rows takes about 12 minutes now!!!
> As I said I wrote a function to insert the rows (PL/pgSQL). All values were
> inserted inside a single function call; I always though that a function call
> would be executed inside a tran
Tom Lane wrote:
> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > To insert another 10562 rows takes about 12 minutes now!!!
>
> See
> http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/populate.html
> particularly the point about not committing each INSERT as a separate
> transaction.
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> To insert another 10562 rows takes about 12 minutes now!!!
See
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/populate.html
particularly the point about not committing each INSERT as a separate
transaction.
rega
Hi,
I am wondering about bad INSERT performance compared against the speed of
COPY. (I use 7.2.2 on RedHat 7.2)
I have a table with about 30 fields, some constraints, some indexes, some
foreign key constraints. I use COPY to import old data. Copying about
10562 rows takes about 19 seconds.
For
16 matches
Mail list logo
