Re: [HACKERS] Re: [BUGS] General Bug Report: palloc fails with lots of ANDs and ORs
От | Vadim B. Mikheev |
---|---|
Тема | Re: [HACKERS] Re: [BUGS] General Bug Report: palloc fails with lots of ANDs and ORs |
Дата | |
Msg-id | 34E942DD.5B00A2@sable.krasnoyarsk.su обсуждение исходный текст |
Ответ на | Re: [BUGS] General Bug Report: palloc fails with lots of ANDs and ORs (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Re: [BUGS] General Bug Report: palloc fails with lots of ANDs and ORs
|
Список | 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
В списке pgsql-hackers по дате отправления: