etc and it takes 17 minutes. The big difference
makes me think that i've made an error with my PostgreSQL
configuration. I just can't seem to figure it out.
Could someone perhaps give me some pointers, advice?
Thanks in advance.
Nicky
if that is fast or not. Any further tips would be
welcome.
Thanks everyone.
Nicky
---(end of broadcast)---
TIP 6: explain analyze is your friend
) not in
('14','15','16','17')/
to (removing the NOT): /substr(t0.code,1,2) in ('14','15','16','17')/
it uses the index, but it's not the query that needs to be run anymore.
Greetings,
Nick
Sven Geisler wrote:
Hi Nicky,
Did you tried to create an index to avoid the sequential scans?
Seq Scan
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
Hello Hannes,
The text above the pictures on page 13. Translated in my crappy english.
The confrontation between the Opteron and Woodcrest was inevitable in
this article, but who can add 1 and 1 should have known from the
previous two pages that it doesn't look that good for AMD . Under loads
Jens Schipkowski wrote:
Thanks a lot to all for your tips.
Of course, I am doing all the INSERTs using a transaction. So the cost
per INSERT dropped from 30 ms to 3 ms.
The improvement factor matches with the hint by Brian Hurt.
Sorry, I forgot to mention we are using PostgreSQL 8.1.4.
