From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Gunther <raj(at)gusw(dot)net> |
Cc: | 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, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Subject: | Re: Out of Memory errors are frustrating as heck! |
Date: | 2019-04-18 15:21:28 |
Message-ID: | 20190418152128.xvohrneyw5e7icl5@development |
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 lively back and forth getting to the bottom of this, suddenly
>my last nights follow-up remained completely without reply. I wonder
>if it even got received. For those who read their emails with modern
>readers (I know I too am from a time where I wrote everything in plain
>text) I marked some important questions in bold.
>
It was received (and it's visible in the archives). It's right before
easter, so I guess some people may be already on a vaction.
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
The number of tables involved in the query is not that high, and this
would allo us to generate a data set approximating your data. The one
thing this can't do is showing how it's affected by WHERE conditions.
(b) export data for join keys
This is similar to (a), but it would allow filtering data by the WHERE
conditions first. The amount of data would be higher, although we only
need data from the columns used as join keys.
Of course, if those key values contain sensitive data, it may not be
possible, but perhaps you could hash it in some way.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2019-04-18 15:33:57 | Re: Best Filesystem for PostgreSQL |
Previous Message | Mahmoud Moharam | 2019-04-18 06:15:17 | Fwd: iscsi performance |