Re: [HACKERS] Re: [BUGS] General Bug Report: palloc fails with lots of ANDs and ORs

From: "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: David Hartwig <daveh(at)insightdist(dot)com>, PostgreSQL-development <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Re: [BUGS] General Bug Report: palloc fails with lots of ANDs and ORs
Date: 1998-02-17 07:57:17
Message-ID: 34E942DD.5B00A2@sable.krasnoyarsk.su
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> >
> > select count(*) from outlet
> > where
> > (number = 1 and number = 1 and number = 1) or
> > (number = 1 and number = 1 and number = 1) or
> > (number = 1 and number = 1 and number = 1) or
> > (number = 1 and number = 1 and number = 1) or
> > (number = 1 and number = 1 and number = 1) or
> > (number = 1 and number = 1 and number = 1) or
> > (number = 1 and number = 1 and number = 1) or
> > (number = 1 and number = 1 and number = 1) or
> > (number = 1 and number = 1 and number = 1);
> >
> > Not pretty but it makes the point. Take out two OR clauses and the query
> > works fine (but a bit slow).
> >
> > The above query is all it takes to use up all 130000 Kbytes of memory.
> > And, since the query takes a long time to finally fail, I was able to
> > observe the memory consumption.

Optimizator tries to transform qual above into AND clause with
3 (# of and-ed clauses) ^ 9 (# of OR-s) = 19683 args (each arg
is OR clause with 9 op. expressions. My estimation for current
cnfify() code is that this will require =~ 500Mb of memory :)
I made little changes - just to free memory when it's possible:

current code with free-ing

6 ORs 14.3 Mb 4.3 Mb
7 ORs 53 Mb 10.3 Mb
8 ORs estimation: ~ 160 Mb 30.6 MB

I'm not sure should I aplly my changes or not - it doesn't fix
problem, just reduces memory impact. It obviously can't help you,
David, in your real example (3 ^ 28 = 22876792454961 clauses - he he :).

Resume: cnfify() makes mathematically strong but in some cases
practically unwise work. I can't fix this for 6.3

Vadim

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SARZ 1998-02-17 08:52:50 Re: Subselects open issue Nr. NEW
Previous Message Brook Milligan 1998-02-17 07:19:39 results of regression tests: NetBSD/i386 v1.3