Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: vadim(at)sable(dot)krasnoyarsk(dot)su (Vadim B(dot) Mikheev)
Cc: daveh(at)insightdist(dot)com, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: [BUGS] General Bug Report: palloc fails with lots of ANDs and ORs
Date: 1998-03-16 05:09:01
Message-ID: 199803160509.AAA22496@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Added to TODO list.


> 
> > >
> > > 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
> 


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-03-16 05:10:39
Subject: Re: [HACKERS] Memory leaks for large objects
Previous:From: Bruce MomjianDate: 1998-03-16 05:08:03
Subject: Re: [HACKERS] spin locks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group