From: | Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Another nasty cache problem |
Date: | 2000-02-04 17:11:53 |
Message-ID: | 20000204171153.D3402@quartz.newn.cam.ac.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
It seems that I am still tracking problems, but each time they turn out to
have a different cause: A slight variant on the select that caused memory
to run out gives
newnham=# select crsids.surname, "tblPerson"."Surname" from crsids,"tblPerson" where crsids.usn="tblPerson"."USN"::int4;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
Nested Loop (cost=66496.62 rows=34359 width=40)
-> Seq Scan on tblPerson (cost=157.62 rows=2625 width=24)
-> Seq Scan on crsids (cost=25.27 rows=584 width=16)
this is the table I based the memory hog on (2600*600). The backend closes
instantly ie., no memory usage! And, as before, it is hard to find a test case
that will do the same as repeatably (ie., test case never crashes, the
above case crashes every single time). "tblPerson", as its strange
capitalisation suggests, was imported from M$ access via ODBC.
select test.txt,test2.var from test,test2 where test2.i=test.var::int4;
Nested Loop (cost=63504.80 rows=2600 width=40)
-> Seq Scan on test2 (cost=24.80 rows=600 width=16)
-> Seq Scan on test (cost=105.80 rows=2600 width=24)
works fine.
Any thoughts on where to look?
Cheers,
Patrick
From | Date | Subject | |
---|---|---|---|
Next Message | Marten Feldtmann | 2000-02-04 18:15:31 | Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL |
Previous Message | Ed Loehr | 2000-02-04 16:39:05 | Re: [HACKERS] PC Week Labs benchmark results |