| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Taylor Vesely <tvesely(at)pivotal(dot)io>, Adam Lee <ali(at)pivotal(dot)io>, Melanie Plageman <mplageman(at)pivotal(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Memory-Bounded Hash Aggregation |
| Date: | 2020-01-25 01:16:47 |
| Message-ID: | CAH2-WznXPuKOee6EMxc7jD4vSQv=yFVVTz6gridGkmzxTSkyNA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jan 24, 2020 at 5:01 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> Unfortunately, I'm seeing some bad behavior (at least in some cases)
> with logtape.c, where it's spending a lot of time qsorting the list of
> free blocks. Adam, did you also see this during your perf tests? It
> seems to be worst with lower work_mem settings and a large number of
> input groups (perhaps there are just too many small tapes?).
That sounds weird. Might be pathological in some sense.
I have a wild guess for you. Maybe this has something to do with the
"test for presorted input" added by commit a3f0b3d68f9. That can
perform very badly when the input is almost sorted, but has a few
tuples that are out of order towards the end. (I have called these
"banana skin tuples" in the past.)
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-01-25 02:14:55 | Re: Duplicate Workers entries in some EXPLAIN plans |
| Previous Message | Jeff Davis | 2020-01-25 01:01:35 | Re: Memory-Bounded Hash Aggregation |