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
