Dan Field wrote:
On 24 May 2004, at 14:37, Tom Lane wrote:
Dan Field <[EMAIL PROTECTED]> writes:
I have a similar problem with just one of my queries (although it isn't
a sub select):
You really ought to vacuum and/or analyze occasionally. The EXPLAIN
results show that the planner hasn't got any
On 24 May 2004, at 14:37, Tom Lane wrote:
Dan Field <[EMAIL PROTECTED]> writes:
I have a similar problem with just one of my queries (although it
isn't
a sub select):
You really ought to vacuum and/or analyze occasionally. The EXPLAIN
results show that the planner hasn't got any non-default stati
Dan Field <[EMAIL PROTECTED]> writes:
> I have a similar problem with just one of my queries (although it isn't
> a sub select):
You really ought to vacuum and/or analyze occasionally. The EXPLAIN
results show that the planner hasn't got any non-default statistics
for any of these tables.
On 23 May 2004, at 19:32, Alexander M. Pravking wrote:
BTW, after cancelling the original query postgres freed all the memory,
and used ~7M again, so the leak was not "forever".
I have a similar problem with just one of my queries (although it isn't a sub select):
SELECT
da_records.*
FROM
d
On Sun, May 23, 2004 at 12:28:18PM -0400, Tom Lane wrote:
> "Alexander M. Pravking" <[EMAIL PROTECTED]> writes:
> > I've got a memory usage problem when I try to do a subselect on the same
> > table as the main select (PostgreSQL 7.3.4 on FreeBSD). Here's my query:
> > ...
> > The "services" table
"Alexander M. Pravking" <[EMAIL PROTECTED]> writes:
> I've got a memory usage problem when I try to do a subselect on the same
> table as the main select (PostgreSQL 7.3.4 on FreeBSD). Here's my query:
> ...
> The "services" table is indexed only on "id" column and has about a
> thousand tuples. sr
Hello, PostgreSQL users and developers.
I've got a memory usage problem when I try to do a subselect on the same
table as the main select (PostgreSQL 7.3.4 on FreeBSD). Here's my query:
SELECT sreq(s1.id, 'ipacct_ip', now()), s1.*
FROMservices s1
WHERE EXISTS (
SELECT 1
John Hasler wrote:
>
> Carolyn Wong writes:
> > This program seems to use a lot of the memory on the linux server, and
> > the memory doesn't seem to be released at the end of execution.
>
> Are you quite certain that this is actually what is happening? Linux
> memory usage can be confusing.
Carolyn Wong writes:
> This program seems to use a lot of the memory on the linux server, and
> the memory doesn't seem to be released at the end of execution.
Are you quite certain that this is actually what is happening? Linux
memory usage can be confusing.
--
John Hasler
[EMAIL PROTECTED] (J
Ms. Wong,
> This program seems to use a lot of the memory on the
> linux server, and
> the memory doesn't seem to be released at the end of
> execution. The same
> thing occurs when I try to connect to the database from
> MS Access via
> ODBC.
It's been my experience that Win32 ODBC does not dr
I have a Borland C++ program (running on NT server) which connects to
PostgresSQL (V6.5) via ODBC (V6.5). The program reads data file and
updates database at regular intervals. The program has close all
connections when execution finishes.
This program seems to use a lot of the memory on the lin
11 matches
Mail list logo
