Re: Increase value of OUTER_VAR
| От | Aleksander Alekseev |
|---|---|
| Тема | Re: Increase value of OUTER_VAR |
| Дата | |
| Msg-id | CAJ7c6TOaeR=aUDaA1c0YWuctJGaTQzP-2a0AaO5ZVbbYFwQfDA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Increase value of OUTER_VAR (Andrey Lepikhov <a.lepikhov@postgrespro.ru>) |
| Список | pgsql-hackers |
Hi Andrey,
> >> only performance issues
> >
> > That's interesting. Any chance you could share the hardware
> > description, the configuration file, and steps to reproduce with us?
> >
> I didn't control execution time exactly. Because it is a join of two
> empty tables. As I see, this join used most part of 48GB RAM memory,
> planned all day on a typical 6 amd cores computer.
> I guess this is caused by sequental traversal of the partition list in
> some places in the optimizer.
> If it makes practical sense, I could investigate reasons for such poor
> performance.
--
Best regards,
Aleksander Alekseev
> >> only performance issues
> >
> > That's interesting. Any chance you could share the hardware
> > description, the configuration file, and steps to reproduce with us?
> >
> I didn't control execution time exactly. Because it is a join of two
> empty tables. As I see, this join used most part of 48GB RAM memory,
> planned all day on a typical 6 amd cores computer.
> I guess this is caused by sequental traversal of the partition list in
> some places in the optimizer.
> If it makes practical sense, I could investigate reasons for such poor
> performance.
Let's say, any information regarding bottlenecks that affect real users with real queries is of interest. Artificially created queries that are unlikely to be ever executed by anyone are not.
--
Best regards,
Aleksander Alekseev
В списке pgsql-hackers по дате отправления: