From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Gunther <raj(at)gusw(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Out of Memory errors are frustrating as heck! |
Date: | 2019-04-19 21:01:17 |
Message-ID: | 20190419210117.GR2854@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Apr 17, 2019 at 11:52:44PM -0400, Gunther wrote:
> Hi guys. I don't want to be pushy, but I found it strange that after so much
Were you able to reproduce the issue in some minimized way ? Like after
joining fewer tables or changing to join with fewer join conditions ?
On Thu, Apr 18, 2019 at 05:21:28PM +0200, Tomas Vondra wrote:
> As for the issue - I think the current hypothesis is that the data
> distribution is skewed in some strange way, triggering some unexpected
> behavior in hash join. That seems plausible, but it's really hard to
> investigate without knowing anything about the data distribution :-(
>
> It would be possible to do at least one of these two things:
>
> (a) export pg_stats info about distribution of the join keys
For starts, could you send the MCVs, maybe with some variation on this query ?
https://wiki.postgresql.org/wiki/Slow_Query_Questions#Statistics:_n_distinct.2C_MCV.2C_histogram
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Gunther | 2019-04-20 03:34:54 | Re: Out of Memory errors are frustrating as heck! |
Previous Message | Gaetano Mendola | 2019-04-19 20:28:38 | Re: Out of Memory errors are frustrating as heck! |