pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: Default setting for enable_hashagg_disk (hash_mem)
26+ messages / 9 participants
[nested] [flat]
* Re: Default setting for enable_hashagg_disk (hash_mem)
@ 2020-07-03 02:46 Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:56 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
0 siblings, 2 replies; 26+ messages in thread
From: Justin Pryzby @ 2020-07-03 02:46 UTC (permalink / raw)
To: Peter Geoghegan <pg@bowt.ie>; +Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>; Bruce Momjian <bruce@momjian.us>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Thu, Jul 02, 2020 at 07:05:48PM -0700, Peter Geoghegan wrote:
> On Mon, Jun 29, 2020 at 2:46 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > On Mon, Jun 29, 2020 at 2:22 PM Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
> > > I agree with this, and I'm mostly OK with having hash_mem. In fact, from
> > > the proposals in this thread I like it the most - as long as it's used
> > > both during planning and execution. It's a pretty clear solution.
> >
> > Great.
> >
> > It's not trivial to write the patch, since there are a few tricky
> > cases. For example, maybe there is some subtlety in nodeAgg.c with
> > AGG_MIXED cases.
>
> Attached is an attempt at this. I have not been particularly thorough,
Thanks for putting it together, I agree that hash_mem seems to be an obvious
"escape hatch" that generalizes existing GUCs and independently useful.
> anything else). I still think that the new GUC should work as a
> multiplier of work_mem, or something else along those lines, though
> for now it's just an independent work_mem used for hashing. I bring it
> up again because I'm concerned about users that upgrade to Postgres 13
> incautiously, and find that hashing uses *less* memory than before.
> Many users probably get away with setting work_mem quite high across
> the board. At the very least, hash_mem should be ignored when it's set
> to below work_mem (which isn't what the patch does).
I feel it should same as work_mem, as it's written, and not a multiplier.
And actually I don't think a lower value should be ignored: "mechanism not
policy". Do we refuse atypical values of maintenance_work_mem < work_mem ?
I assumed that hash_mem would default to -1, which would mean "fall back to
work_mem". We'd then advise users to increase it if they have an issue in v13
with performance of hashes spilled to disk. (And maybe in other cases, too.)
I read the argument that hash tables are a better use of RAM than sort.
However it seems like setting the default to greater than work_mem is a
separate change than providing the mechanism allowing user to do so. I guess
the change in default is intended to mitigate the worst possible behavior
change someone might experience in v13 hashing, and might be expected to
improve "out of the box" performance. I'm not opposed to it, but it's not an
essential part of the patch.
In nodeHash.c, you missed an underscore:
+ * Target in-memory hashtable size is hashmem kilobytes.
--
Justin
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
@ 2020-07-03 02:58 ` Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 26+ messages in thread
From: Bruce Momjian @ 2020-07-03 02:58 UTC (permalink / raw)
To: Justin Pryzby <pryzby@telsasoft.com>; +Cc: Peter Geoghegan <pg@bowt.ie>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Thu, Jul 2, 2020 at 09:46:49PM -0500, Justin Pryzby wrote:
> On Thu, Jul 02, 2020 at 07:05:48PM -0700, Peter Geoghegan wrote:
> > anything else). I still think that the new GUC should work as a
> > multiplier of work_mem, or something else along those lines, though
> > for now it's just an independent work_mem used for hashing. I bring it
> > up again because I'm concerned about users that upgrade to Postgres 13
> > incautiously, and find that hashing uses *less* memory than before.
> > Many users probably get away with setting work_mem quite high across
> > the board. At the very least, hash_mem should be ignored when it's set
> > to below work_mem (which isn't what the patch does).
>
> I feel it should same as work_mem, as it's written, and not a multiplier.
>
> And actually I don't think a lower value should be ignored: "mechanism not
> policy". Do we refuse atypical values of maintenance_work_mem < work_mem ?
>
> I assumed that hash_mem would default to -1, which would mean "fall back to
> work_mem". We'd then advise users to increase it if they have an issue in v13
> with performance of hashes spilled to disk. (And maybe in other cases, too.)
Uh, with this patch, don't we really have sort_mem and hash_mem, but
hash_mem default to sort_mem, or something like that. If hash_mem is a
multiplier, it would make more sense to keep the work_mem name.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
@ 2020-07-03 03:00 ` Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
0 siblings, 1 reply; 26+ messages in thread
From: Bruce Momjian @ 2020-07-03 03:00 UTC (permalink / raw)
To: Justin Pryzby <pryzby@telsasoft.com>; +Cc: Peter Geoghegan <pg@bowt.ie>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Thu, Jul 2, 2020 at 10:58:34PM -0400, Bruce Momjian wrote:
> On Thu, Jul 2, 2020 at 09:46:49PM -0500, Justin Pryzby wrote:
> > On Thu, Jul 02, 2020 at 07:05:48PM -0700, Peter Geoghegan wrote:
> > > anything else). I still think that the new GUC should work as a
> > > multiplier of work_mem, or something else along those lines, though
> > > for now it's just an independent work_mem used for hashing. I bring it
> > > up again because I'm concerned about users that upgrade to Postgres 13
> > > incautiously, and find that hashing uses *less* memory than before.
> > > Many users probably get away with setting work_mem quite high across
> > > the board. At the very least, hash_mem should be ignored when it's set
> > > to below work_mem (which isn't what the patch does).
> >
> > I feel it should same as work_mem, as it's written, and not a multiplier.
> >
> > And actually I don't think a lower value should be ignored: "mechanism not
> > policy". Do we refuse atypical values of maintenance_work_mem < work_mem ?
> >
> > I assumed that hash_mem would default to -1, which would mean "fall back to
> > work_mem". We'd then advise users to increase it if they have an issue in v13
> > with performance of hashes spilled to disk. (And maybe in other cases, too.)
>
> Uh, with this patch, don't we really have sort_mem and hash_mem, but
> hash_mem default to sort_mem, or something like that. If hash_mem is a
> multiplier, it would make more sense to keep the work_mem name.
Also, I feel this is all out of scope for PG 13, frankly. I think our
only option is to revert the hash spill entirely, and return to PG 13
behavior, if people are too worried about hash performance regression.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
@ 2020-07-03 03:35 ` Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 26+ messages in thread
From: Peter Geoghegan @ 2020-07-03 03:35 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Thu, Jul 2, 2020 at 8:00 PM Bruce Momjian <bruce@momjian.us> wrote:
> Also, I feel this is all out of scope for PG 13, frankly. I think our
> only option is to revert the hash spill entirely, and return to PG 13
> behavior, if people are too worried about hash performance regression.
But the problem isn't really the hashaggs-that-spill patch itself.
Rather, the problem is the way that work_mem is supposed to behave in
general, and the impact that that has on hash aggregate now that it
has finally been brought into line with every other kind of executor
node. There just isn't much reason to think that we should give the
same amount of memory to a groupagg + sort as a hash aggregate. The
patch more or less broke an existing behavior that is itself
officially broken. That is, the problem that we're trying to fix here
is only a problem to the extent that the previous scheme isn't really
operating as intended (because grouping estimates are inherently very
hard). A revert doesn't seem like it helps anyone.
I accept that the idea of inventing hash_mem to fix this problem now
is unorthodox. In a certain sense it solves problems beyond the
problems that we're theoretically obligated to solve now. But any
"more conservative" approach that I can think of seems like a big
mess.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
@ 2020-07-03 14:08 ` Bruce Momjian <bruce@momjian.us>
2020-07-03 14:56 ` Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 19:50 ` Re: Default setting for enable_hashagg_disk (hash_mem) Alvaro Herrera <alvherre@2ndquadrant.com>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-07 17:12 ` Re: Default setting for enable_hashagg_disk (hash_mem) Andres Freund <andres@anarazel.de>
0 siblings, 4 replies; 26+ messages in thread
From: Bruce Momjian @ 2020-07-03 14:08 UTC (permalink / raw)
To: Peter Geoghegan <pg@bowt.ie>; +Cc: Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Thu, Jul 2, 2020 at 08:35:40PM -0700, Peter Geoghegan wrote:
> But the problem isn't really the hashaggs-that-spill patch itself.
> Rather, the problem is the way that work_mem is supposed to behave in
> general, and the impact that that has on hash aggregate now that it
> has finally been brought into line with every other kind of executor
> node. There just isn't much reason to think that we should give the
> same amount of memory to a groupagg + sort as a hash aggregate. The
> patch more or less broke an existing behavior that is itself
> officially broken. That is, the problem that we're trying to fix here
> is only a problem to the extent that the previous scheme isn't really
> operating as intended (because grouping estimates are inherently very
> hard). A revert doesn't seem like it helps anyone.
>
> I accept that the idea of inventing hash_mem to fix this problem now
> is unorthodox. In a certain sense it solves problems beyond the
> problems that we're theoretically obligated to solve now. But any
> "more conservative" approach that I can think of seems like a big
> mess.
Well, the bottom line is that we are designing features during beta.
People are supposed to be testing PG 13 behavior during beta, including
optimizer behavior. We don't even have a user report yet of a
regression compared to PG 12, or one that can't be fixed by increasing
work_mem.
If we add a new behavior to PG 13, we then have the pre-PG 13 behavior,
the pre-patch behavior, and the post-patch behavior. How are people
supposed to test all of that? Add to that that some don't even feel we
need a new behavior, which is delaying any patch from being applied.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
@ 2020-07-03 14:56 ` Justin Pryzby <pryzby@telsasoft.com>
3 siblings, 0 replies; 26+ messages in thread
From: Justin Pryzby @ 2020-07-03 14:56 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Peter Geoghegan <pg@bowt.ie>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Fri, Jul 03, 2020 at 10:08:08AM -0400, Bruce Momjian wrote:
> On Thu, Jul 2, 2020 at 08:35:40PM -0700, Peter Geoghegan wrote:
> > But the problem isn't really the hashaggs-that-spill patch itself.
> > Rather, the problem is the way that work_mem is supposed to behave in
> > general, and the impact that that has on hash aggregate now that it
> > has finally been brought into line with every other kind of executor
> > node. There just isn't much reason to think that we should give the
> > same amount of memory to a groupagg + sort as a hash aggregate. The
> > patch more or less broke an existing behavior that is itself
> > officially broken. That is, the problem that we're trying to fix here
> > is only a problem to the extent that the previous scheme isn't really
> > operating as intended (because grouping estimates are inherently very
> > hard). A revert doesn't seem like it helps anyone.
> >
> > I accept that the idea of inventing hash_mem to fix this problem now
> > is unorthodox. In a certain sense it solves problems beyond the
> > problems that we're theoretically obligated to solve now. But any
> > "more conservative" approach that I can think of seems like a big
> > mess.
>
> Well, the bottom line is that we are designing features during beta.
> People are supposed to be testing PG 13 behavior during beta, including
> optimizer behavior. We don't even have a user report yet of a
> regression compared to PG 12, or one that can't be fixed by increasing
> work_mem.
>
> If we add a new behavior to PG 13, we then have the pre-PG 13 behavior,
> the pre-patch behavior, and the post-patch behavior. How are people
> supposed to test all of that? Add to that that some don't even feel we
> need a new behavior, which is delaying any patch from being applied.
If we default hash_mem=-1, the post-patch behavior by default would be same as
the pre-patch behavior.
Actually, another reason it should be -1 is simply to reduce the minimum,
essential number of GUCs everyone has to change or review on a new installs of
a dedicated or nontrivial instance. shared_buffers, max_wal_size,
checkpoint_timeout, eff_cache_size, work_mem.
I don't think anybody said it before, but now it occurs to me that one
advantage of making hash_mem a multiplier (I'm thinking of
hash_mem_scale_factor) rather than an absolute is that one wouldn't need to
remember to increase hash_mem every time they increase work_mem. Otherwise,
this is kind of a foot-gun: hash_mem would default to 16MB, and people
experiencing poor performance would increase work_mem to 256MB like they've
been doing for decades, and see no effect. Or someone would increase work_mem
from 4MB to 256MB, which exceeds hash_mem default of 16MB, so then (if Peter
has his way) hash_mem is ignored.
Due to these behaviors, I'll retract my previous preference:
| "I feel it should same as work_mem, as it's written, and not a multiplier."
I think the better ideas are:
- hash_mem=-1
- hash_mem_scale_factor=1 ?
Maybe as a separate patch we'd set default hash_mem_scale_factor=4, possibly
only in master not and v13.
--
Justin
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
@ 2020-07-03 19:50 ` Alvaro Herrera <alvherre@2ndquadrant.com>
3 siblings, 0 replies; 26+ messages in thread
From: Alvaro Herrera @ 2020-07-03 19:50 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Peter Geoghegan <pg@bowt.ie>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On 2020-Jul-03, Bruce Momjian wrote:
> Well, the bottom line is that we are designing features during beta.
Well, we're designing a way for users to interact the new feature.
The feature itself is already in, and it works well in general terms. I
expect that the new behavior is a win in the majority of cases, and the
problem being discussed here will only manifest as a regression in
corner cases. (I don't have data to back this up, but if this weren't
the case we would have realized much earlier).
It seem to me we're designing a solution to a problem that was found
during testing, which seems perfectly acceptable to me. I don't see
grounds for reverting the behavior and I haven't seen anyone suggesting
that it would be an appropriate solution to the issue.
> If we add a new behavior to PG 13, we then have the pre-PG 13 behavior,
> the pre-patch behavior, and the post-patch behavior. How are people
> supposed to test all of that?
They don't have to. We tell them that we added some new tweak for a new
pg13 feature in beta3 and that's it.
> Add to that that some don't even feel we
> need a new behavior, which is delaying any patch from being applied.
If we don't need any new behavior, then we would just close the open
item and call the current state good, no?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
@ 2020-07-04 09:19 ` Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
3 siblings, 1 reply; 26+ messages in thread
From: Amit Kapila @ 2020-07-04 09:19 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Peter Geoghegan <pg@bowt.ie>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Fri, Jul 3, 2020 at 7:38 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> On Thu, Jul 2, 2020 at 08:35:40PM -0700, Peter Geoghegan wrote:
> > But the problem isn't really the hashaggs-that-spill patch itself.
> > Rather, the problem is the way that work_mem is supposed to behave in
> > general, and the impact that that has on hash aggregate now that it
> > has finally been brought into line with every other kind of executor
> > node. There just isn't much reason to think that we should give the
> > same amount of memory to a groupagg + sort as a hash aggregate. The
> > patch more or less broke an existing behavior that is itself
> > officially broken. That is, the problem that we're trying to fix here
> > is only a problem to the extent that the previous scheme isn't really
> > operating as intended (because grouping estimates are inherently very
> > hard). A revert doesn't seem like it helps anyone.
> >
> > I accept that the idea of inventing hash_mem to fix this problem now
> > is unorthodox. In a certain sense it solves problems beyond the
> > problems that we're theoretically obligated to solve now. But any
> > "more conservative" approach that I can think of seems like a big
> > mess.
>
> We don't even have a user report yet of a
> regression compared to PG 12, or one that can't be fixed by increasing
> work_mem.
>
Yeah, this is exactly the same point I have raised above. I feel we
should wait before designing any solution to match pre-13 behavior for
hashaggs to see what percentage of users face problems related to this
and how much is a problem for them to increase work_mem to avoid
regression. Say, if only less than 1% of users face this problem and
some of them are happy by just increasing work_mem then we might not
need to do anything. OTOH, if 10% users face this problem and most of
them don't want to increase work_mem then it would be evident that we
need to do something about it and we can probably provide a guc at
that stage for them to revert to old behavior and do some advanced
solution in the master branch. I am not sure what is the right thing
to do here but it seems to me we are designing a solution based on the
assumption that we will have a lot of users who will be hit by this
problem and would be unhappy by the new behavior.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
@ 2020-07-04 20:53 ` Jeff Davis <pgsql@j-davis.com>
2020-07-05 23:47 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-06 10:29 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 2 replies; 26+ messages in thread
From: Jeff Davis @ 2020-07-04 20:53 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; Bruce Momjian <bruce@momjian.us>; +Cc: Peter Geoghegan <pg@bowt.ie>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Sat, 2020-07-04 at 14:49 +0530, Amit Kapila wrote:
> > We don't even have a user report yet of a
> > regression compared to PG 12, or one that can't be fixed by
> > increasing
> > work_mem.
> >
>
> Yeah, this is exactly the same point I have raised above. I feel we
> should wait before designing any solution to match pre-13 behavior
> for
> hashaggs to see what percentage of users face problems related to
> this
> and how much is a problem for them to increase work_mem to avoid
> regression.
I agree that it's good to wait for actual problems. But the challenge
is that we can't backport an added GUC. Are there other, backportable
changes we could potentially make if a lot of users have a problem with
v13 after release? Or will any users who experience a problem need to
wait for v14?
I'm OK not having a GUC, but we need consensus around what our response
will be if a user experiences a regression. If our only answer is
"tweak X, Y, and Z; and if that doesn't work, wait for v14" then I'd
like almost everyone to be on board with that. If we have some
backportable potential solutions, that gives us a little more
confidence that we can still get that user onto v13 (even if they have
to wait for a point release).
Without some backportable potential solutions, I'm inclined to ship
with either one or two escape-hatch GUCs, with warnings that they
should be used as a last resort. Hopefully users will complain on the
lists (so we understand the problem) before setting them.
It's not very principled, and we may be stuck with some cruft, but it
mitigates the risk a lot. There's a good chance we can remove them
later, especially if it's part of a larger overhall of
work_mem/hash_mem (which might happen fairly soon, given the interest
in this thread), or if we change something about HashAgg that makes the
GUCs harder to maintain.
Regards,
Jeff Davis
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
@ 2020-07-05 23:47 ` Peter Geoghegan <pg@bowt.ie>
2020-07-07 04:57 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
1 sibling, 1 reply; 26+ messages in thread
From: Peter Geoghegan @ 2020-07-05 23:47 UTC (permalink / raw)
To: Jeff Davis <pgsql@j-davis.com>; +Cc: Amit Kapila <amit.kapila16@gmail.com>; Bruce Momjian <bruce@momjian.us>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Sat, Jul 4, 2020 at 1:54 PM Jeff Davis <pgsql@j-davis.com> wrote:
> I agree that it's good to wait for actual problems. But the challenge
> is that we can't backport an added GUC. Are there other, backportable
> changes we could potentially make if a lot of users have a problem with
> v13 after release?
I doubt that there are.
> I'm OK not having a GUC, but we need consensus around what our response
> will be if a user experiences a regression. If our only answer is
> "tweak X, Y, and Z; and if that doesn't work, wait for v14" then I'd
> like almost everyone to be on board with that.
I'm practically certain that there will be users that complain about
regressions. It's all but inevitable given that in general grouping
estimates are often wrong by orders of magnitude.
> Without some backportable potential solutions, I'm inclined to ship
> with either one or two escape-hatch GUCs, with warnings that they
> should be used as a last resort. Hopefully users will complain on the
> lists (so we understand the problem) before setting them.
Where does that leave the hash_mem idea (or some other similar proposal)?
I think that we should offer something like hash_mem that can work as
a multiple of work_mem, for the reason that Justin mentioned recently.
This can be justified as something that more or less maintains some
kind of continuity with the old design.
I think that it should affect hash join too, though I suppose that
that part might be controversial -- that is certainly more than an
escape hatch for this particular problem. Any thoughts on that?
> It's not very principled, and we may be stuck with some cruft, but it
> mitigates the risk a lot. There's a good chance we can remove them
> later, especially if it's part of a larger overhall of
> work_mem/hash_mem (which might happen fairly soon, given the interest
> in this thread), or if we change something about HashAgg that makes the
> GUCs harder to maintain.
There are several reasons to get rid of work_mem entirely in the
medium to long term. Some relatively obvious, others less so.
An example in the latter category is "hash teams" [1]: a design that
teaches multiple hash operations (e.g. a hash join and a hash
aggregate that hash on the same columns) to cooperate in processing
their inputs. It's more or less the hashing equivalent of what are
sometimes called "interesting sort orders" (e.g. cases where the same
sort/sort order is used by both a merge join and a group aggregate).
The hash team controls spilling behavior for related hash nodes as a
whole. That's the most sensible way of thinking about the related hash
nodes, to enable a slew of optimizations. For example, I think that it
enables bushy plans with multiple hash joins that can have much lower
high watermark memory consumption.
This hash teams business seems quite important in general, but it is
fundamentally incompatible with the work_mem model, which supposes
that each node exists on its own in a vacuum. (I suspect you already
knew about this, Jeff, but not everyone will.)
[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.114.3183&rep=rep1&type=pdf
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-05 23:47 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
@ 2020-07-07 04:57 ` Jeff Davis <pgsql@j-davis.com>
2020-07-07 05:02 ` Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-07 12:54 ` Re: Default setting for enable_hashagg_disk (hash_mem) David Rowley <dgrowleyml@gmail.com>
0 siblings, 2 replies; 26+ messages in thread
From: Jeff Davis @ 2020-07-07 04:57 UTC (permalink / raw)
To: Peter Geoghegan <pg@bowt.ie>; +Cc: Amit Kapila <amit.kapila16@gmail.com>; Bruce Momjian <bruce@momjian.us>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Sun, 2020-07-05 at 16:47 -0700, Peter Geoghegan wrote:
> Where does that leave the hash_mem idea (or some other similar
> proposal)?
hash_mem is acceptable to me if the consensus is moving toward that,
but I'm not excited about it.
It would be one thing if hash_mem was a nice clean solution. But it
doesn't seem like a clean solution to me; and it's likely that it will
get in the way of the next person who tries to improve the work_mem
situation.
> I think that we should offer something like hash_mem that can work as
> a multiple of work_mem, for the reason that Justin mentioned
> recently.
> This can be justified as something that more or less maintains some
> kind of continuity with the old design.
Didn't Justin argue against using a multiplier?
https://postgr.es/m/20200703024649.GJ4107@telsasoft.com
> I think that it should affect hash join too, though I suppose that
> that part might be controversial -- that is certainly more than an
> escape hatch for this particular problem. Any thoughts on that?
If it's called hash_mem, then I guess it needs to affect HJ. If not, it
should have a different name.
> There are several reasons to get rid of work_mem entirely in the
> medium to long term. Some relatively obvious, others less so.
Agreed.
It seems like the only argument against the escape hatch GUCs is that
they are cruft and we will end up stuck with them. But if we are
dispensing with work_mem in a few releases, surely we'd need to
dispense with hash_mem or the proposed escape-hatch GUCs anyway.
> An example in the latter category is "hash teams" [1]: a design that
> teaches multiple hash operations (e.g. a hash join and a hash
> aggregate that hash on the same columns) to cooperate in processing
> their inputs.
Cool! It would certainly be nice to share the partitioning work between
a HashAgg and a HJ.
Regards,
Jeff Davis
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-05 23:47 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-07 04:57 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
@ 2020-07-07 05:02 ` Justin Pryzby <pryzby@telsasoft.com>
1 sibling, 0 replies; 26+ messages in thread
From: Justin Pryzby @ 2020-07-07 05:02 UTC (permalink / raw)
To: Jeff Davis <pgsql@j-davis.com>; +Cc: Peter Geoghegan <pg@bowt.ie>; Amit Kapila <amit.kapila16@gmail.com>; Bruce Momjian <bruce@momjian.us>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Mon, Jul 06, 2020 at 09:57:08PM -0700, Jeff Davis wrote:
> > I think that we should offer something like hash_mem that can work as
> > a multiple of work_mem, for the reason that Justin mentioned
> > recently.
> > This can be justified as something that more or less maintains some
> > kind of continuity with the old design.
>
> Didn't Justin argue against using a multiplier?
> https://postgr.es/m/20200703024649.GJ4107@telsasoft.com
I recanted.
https://www.postgresql.org/message-id/20200703145620.GK4107@telsasoft.com
--
Justin
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-05 23:47 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-07 04:57 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
@ 2020-07-07 12:54 ` David Rowley <dgrowleyml@gmail.com>
2020-07-07 13:16 ` Re: Default setting for enable_hashagg_disk (hash_mem) Pavel Stehule <pavel.stehule@gmail.com>
2020-07-07 19:24 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
1 sibling, 2 replies; 26+ messages in thread
From: David Rowley @ 2020-07-07 12:54 UTC (permalink / raw)
To: Jeff Davis <pgsql@j-davis.com>; +Cc: Peter Geoghegan <pg@bowt.ie>; Amit Kapila <amit.kapila16@gmail.com>; Bruce Momjian <bruce@momjian.us>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Tue, 7 Jul 2020 at 16:57, Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Sun, 2020-07-05 at 16:47 -0700, Peter Geoghegan wrote:
> > Where does that leave the hash_mem idea (or some other similar
> > proposal)?
>
> hash_mem is acceptable to me if the consensus is moving toward that,
> but I'm not excited about it.
FWIW, I'm not a fan of the hash_mem idea. It was my impression that we
aimed to provide an escape hatch for people we have become accustomed
to <= PG12 behaviour and hash_mem sounds like it's not that. Surely a
GUC by that name would control what Hash Join does too? Otherwise, it
would be called hashagg_mem. I'd say changing the behaviour of Hash
join is not well aligned to the goal of allowing users to get
something closer to what PG12 did.
I know there has been talk over the years to improve how work_mem
works. I see Tomas mentioned memory grants on the other thread [1]. I
do imagine this is the long term solution to the problem where users
must choose very conservative values for work_mem. We're certainly not
going to get that for PG13, so I do think what we need here is just a
simple escape hatch. I mentioned my thoughts in [2], so won't go over
it again here. Once we've improved the situation in some future
version of postgres, perhaps along the lines of what Tomas mentioned,
then we can get rid of the escape hatch.
Here are my reasons for not liking the hash_mem idea:
1. if it also increases the amount of memory that Hash Join can use
then that makes the partition-wise hash join problem of hash_mem *
npartitions even bigger when users choose to set hash_mem higher than
work_mem to get Hash Agg doing what they're used to.
2. Someone will one day ask for sort_mem and then materialize_mem.
Maybe then cte_mem. Once those are done we might as well just add a
GUC to control every executor node that uses work_mem.
3. I'm working on a Result cache node [3]. It uses a hash table
internally. Should it constraint its memory consumption according to
hash_mem or work_mem? It's not really that obvious to people that it
internally uses a hash table. "Hash" does not appear in the node name.
Do people need to look that up in the documents?
David
[1] https://www.postgresql.org/message-id/20200626235850.gvl3lpfyeobu4evi@development
[2] https://www.postgresql.org/message-id/CAApHDvqFZikXhAGW=UKZKq1_FzHy+XzmUzAJiNj6RWyTHH4UfA@mail.gmail...
[3] https://www.postgresql.org/message-id/CAApHDvrPcQyQdWERGYWx8J+2DLUNgXu+fOSbQ1UscxrunyXyrQ@mail.gmail...
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-05 23:47 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-07 04:57 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-07 12:54 ` Re: Default setting for enable_hashagg_disk (hash_mem) David Rowley <dgrowleyml@gmail.com>
@ 2020-07-07 13:16 ` Pavel Stehule <pavel.stehule@gmail.com>
1 sibling, 0 replies; 26+ messages in thread
From: Pavel Stehule @ 2020-07-07 13:16 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: Jeff Davis <pgsql@j-davis.com>; Peter Geoghegan <pg@bowt.ie>; Amit Kapila <amit.kapila16@gmail.com>; Bruce Momjian <bruce@momjian.us>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
út 7. 7. 2020 v 14:55 odesílatel David Rowley <dgrowleyml@gmail.com> napsal:
> On Tue, 7 Jul 2020 at 16:57, Jeff Davis <pgsql@j-davis.com> wrote:
> >
> > On Sun, 2020-07-05 at 16:47 -0700, Peter Geoghegan wrote:
> > > Where does that leave the hash_mem idea (or some other similar
> > > proposal)?
> >
> > hash_mem is acceptable to me if the consensus is moving toward that,
> > but I'm not excited about it.
>
> FWIW, I'm not a fan of the hash_mem idea. It was my impression that we
> aimed to provide an escape hatch for people we have become accustomed
> to <= PG12 behaviour and hash_mem sounds like it's not that. Surely a
> GUC by that name would control what Hash Join does too? Otherwise, it
> would be called hashagg_mem. I'd say changing the behaviour of Hash
> join is not well aligned to the goal of allowing users to get
> something closer to what PG12 did.
>
> I know there has been talk over the years to improve how work_mem
> works. I see Tomas mentioned memory grants on the other thread [1]. I
> do imagine this is the long term solution to the problem where users
> must choose very conservative values for work_mem. We're certainly not
> going to get that for PG13, so I do think what we need here is just a
> simple escape hatch. I mentioned my thoughts in [2], so won't go over
> it again here. Once we've improved the situation in some future
> version of postgres, perhaps along the lines of what Tomas mentioned,
> then we can get rid of the escape hatch.
>
> Here are my reasons for not liking the hash_mem idea:
>
> 1. if it also increases the amount of memory that Hash Join can use
> then that makes the partition-wise hash join problem of hash_mem *
> npartitions even bigger when users choose to set hash_mem higher than
> work_mem to get Hash Agg doing what they're used to.
> 2. Someone will one day ask for sort_mem and then materialize_mem.
> Maybe then cte_mem. Once those are done we might as well just add a
> GUC to control every executor node that uses work_mem.
> 3. I'm working on a Result cache node [3]. It uses a hash table
> internally. Should it constraint its memory consumption according to
> hash_mem or work_mem? It's not really that obvious to people that it
> internally uses a hash table. "Hash" does not appear in the node name.
> Do people need to look that up in the documents?
>
+1
I share your opinion.
> David
>
> [1]
> https://www.postgresql.org/message-id/20200626235850.gvl3lpfyeobu4evi@development
> [2]
> https://www.postgresql.org/message-id/CAApHDvqFZikXhAGW=UKZKq1_FzHy+XzmUzAJiNj6RWyTHH4UfA@mail.gmail...
> [3]
> https://www.postgresql.org/message-id/CAApHDvrPcQyQdWERGYWx8J+2DLUNgXu+fOSbQ1UscxrunyXyrQ@mail.gmail...
>
>
>
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-05 23:47 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-07 04:57 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-07 12:54 ` Re: Default setting for enable_hashagg_disk (hash_mem) David Rowley <dgrowleyml@gmail.com>
@ 2020-07-07 19:24 ` Peter Geoghegan <pg@bowt.ie>
2020-07-08 01:57 ` Re: Default setting for enable_hashagg_disk (hash_mem) David Rowley <dgrowleyml@gmail.com>
1 sibling, 1 reply; 26+ messages in thread
From: Peter Geoghegan @ 2020-07-07 19:24 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: Jeff Davis <pgsql@j-davis.com>; Amit Kapila <amit.kapila16@gmail.com>; Bruce Momjian <bruce@momjian.us>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Tue, Jul 7, 2020 at 5:55 AM David Rowley <dgrowleyml@gmail.com> wrote:
> FWIW, I'm not a fan of the hash_mem idea. It was my impression that we
> aimed to provide an escape hatch for people we have become accustomed
> to <= PG12 behaviour and hash_mem sounds like it's not that.
The exact scope of the problem is unclear. If it was clear, then we'd
be a lot closer to a resolution than we seem to be. Determining the
scope of the problem is the hardest part of the problem.
All that is ~100% clear now is that some users will experience what
they'll call a regression. Those users will be unhappy, even if and
when they come to understand that technically they're just "living
within their means" for the first time, and were theoretically not
entitled to the performance from earlier versions all along. That's
bad, and we should try our best to avoid or mitigate it.
Sometimes the more ambitious plan (in this case hash_mem) actually has
a greater chance of succeeding, despite solving more problems than the
immediate problem. I don't think that it's reasonable to hold that
against my proposal. It may be that hash_mem is a bad idea based on
the costs and benefits, or the new risks, in which case it should be
rejected. But if it's the best proposal on the table by a clear
margin, then it shouldn't be disqualified for not satisfying the
original framing of the problem.
> Surely a
> GUC by that name would control what Hash Join does too? Otherwise, it
> would be called hashagg_mem. I'd say changing the behaviour of Hash
> join is not well aligned to the goal of allowing users to get
> something closer to what PG12 did.
My tentative hash_mem proposal assumed that hash join would be
affected alongside hash agg, in the obvious way. Yes, that's clearly
beyond the scope of the open item.
The history of some other database systems is instructive. At least a
couple of these systems had something like a work_mem/sort_mem GUC, as
well as a separate hash_mem-like GUC that only affects hashing. It's
sloppy, but nevertheless better than completely ignoring the
fundamental ways in which hashing really is special. This is a way of
papering-over one of the main deficiencies of the general idea of a
work_mem style per-node allocation. Yes, that's pretty ugly.
I think that work_mem would be a lot easier to tune if you assume that
hash-based nodes don't exist (i.e. only merge joins and nestloop joins
are available, plus group aggregate for aggregation). You don't need
to do this as a thought experiment. That really was how things were up
until about the mid-1980s, when increasing memory capacities made hash
join and hash agg in database systems feasible for the first time.
Hashing came after most of the serious work on cost-based optimizers
had already been done. This argues for treating hash-based nodes as
special now, if only to extend work_mem beyond its natural life as a
pragmatic short-term measure. Separately, it argues for a *total
rethink* of how memory is used in the executor in the long term -- it
shouldn't be per-node in a few important cases (I'm thinking of the
"hash teams" design I mentioned on this thread recently, which seems
like a fundamentally better way of doing it).
> We're certainly not
> going to get that for PG13, so I do think what we need here is just a
> simple escape hatch. I mentioned my thoughts in [2], so won't go over
> it again here. Once we've improved the situation in some future
> version of postgres, perhaps along the lines of what Tomas mentioned,
> then we can get rid of the escape hatch.
If it really has to be a simple escape hatch in Postgres 13, then I
could live with a hard disabling of spilling at execution time. That
seems like the most important thing that is addressed by your
proposal. I'm concerned that way too many users will have to use the
escape hatch, and that that misses the opportunity to provide a
smoother experience.
> Here are my reasons for not liking the hash_mem idea:
I'm sure that your objections are valid to varying degrees. But they
could almost be thought of as problems with work_mem itself. I am
trying to come up with a practical way of ameliorating the downsides
of work_mem. I don't for a second imagine that this won't create new
problems. I think that it's the least worst thing right now. I have my
misgivings.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-05 23:47 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-07 04:57 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-07 12:54 ` Re: Default setting for enable_hashagg_disk (hash_mem) David Rowley <dgrowleyml@gmail.com>
2020-07-07 19:24 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
@ 2020-07-08 01:57 ` David Rowley <dgrowleyml@gmail.com>
2020-07-08 03:26 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 1 reply; 26+ messages in thread
From: David Rowley @ 2020-07-08 01:57 UTC (permalink / raw)
To: Peter Geoghegan <pg@bowt.ie>; +Cc: Jeff Davis <pgsql@j-davis.com>; Amit Kapila <amit.kapila16@gmail.com>; Bruce Momjian <bruce@momjian.us>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Wed, 8 Jul 2020 at 07:25, Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Tue, Jul 7, 2020 at 5:55 AM David Rowley <dgrowleyml@gmail.com> wrote:
> > We're certainly not
> > going to get that for PG13, so I do think what we need here is just a
> > simple escape hatch. I mentioned my thoughts in [2], so won't go over
> > it again here. Once we've improved the situation in some future
> > version of postgres, perhaps along the lines of what Tomas mentioned,
> > then we can get rid of the escape hatch.
>
> If it really has to be a simple escape hatch in Postgres 13, then I
> could live with a hard disabling of spilling at execution time. That
> seems like the most important thing that is addressed by your
> proposal. I'm concerned that way too many users will have to use the
> escape hatch, and that that misses the opportunity to provide a
> smoother experience.
Yeah. It's a valid concern. I'd rather nobody would ever have to exit
through the escape hatch either. I don't think anyone here actually
wants that to happen. It's only been proposed to allow users a method
to escape the new behaviour and get back what they're used to.
I think the smoother experience will come in some future version of
PostgreSQL with generally better memory management for work_mem all
round. It's certainly been talked about enough and I don't think
anyone here disagrees that there is a problem with N being unbounded
when it comes to N * work_mem.
I'd really like to see this thread move forward to a solution and I'm
not sure how best to do that. I started by reading back over both this
thread and the original one and tried to summarise what people have
suggested.
I understand some people did change their minds along the way, so I
may have made some mistakes. I could have assumed the latest mindset
overruled, but it was harder to determine that due to the thread being
split.
For hash_mem = Justin [16], PeterG [15], Tomas [7]
hash_mem out of scope for PG13 = Bruce [8], Andres [9]
Wait for reports from users = Amit [10]
Escape hatch that can be removed later when we get something better =
Jeff [11], David [12], Pavel [13], Andres [14], Justin [1]
Add enable_hashagg_spill = Tom [2] (I'm unclear on this proposal. Does
it affect the planner or executor or both?)
Maybe do nothing until we see how things go during beta = Bruce [3]
Just let users set work_mem = Alvaro [4] (I think he changed his mind
after Andres pointed out that changes other nodes in the plan too)
Swap enable_hashagg for a GUC that specifies when spilling should
occur. -1 means work_mem = Robert [17], Amit [18]
hash_mem does not solve the problem = Tomas [6]
David
[1] https://www.postgresql.org/message-id/20200624031443.GV4107@telsasoft.com
[2] https://www.postgresql.org/message-id/2214502.1593019796@sss.pgh.pa.us
[3] https://www.postgresql.org/message-id/20200625182512.GC12486@momjian.us
[4] https://www.postgresql.org/message-id/20200625224422.GA9653@alvherre.pgsql
[5] https://www.postgresql.org/message-id/CAA4eK1K0cgk_8hRyxsvppgoh_Z-NY+UZTcFWB2we6baJ9DXCQw@mail.gmail...
[6] https://www.postgresql.org/message-id/20200627104141.gq7d3hm2tvoqgjjs@development
[7] https://www.postgresql.org/message-id/20200629212229.n3afgzq6xpxrr4cu@development
[8] https://www.postgresql.org/message-id/20200703030001.GD26235@momjian.us
[9] https://www.postgresql.org/message-id/20200707171216.jqxrld2jnxwf5ozv@alap3.anarazel.de
[10] https://www.postgresql.org/message-id/CAA4eK1KfPi6iz0hWxBLZzfVOG_NvOVJL=9UQQirWLpaN=kANTQ@mail.gmail...
[11] https://www.postgresql.org/message-id/8bff2e4e8020c3caa16b61a46918d21b573eaf78.camel@j-davis.com
[12] https://www.postgresql.org/message-id/CAApHDvqFZikXhAGW=UKZKq1_FzHy+XzmUzAJiNj6RWyTHH4UfA@mail.gmail...
[13] https://www.postgresql.org/message-id/CAFj8pRBf1w4ndz-ynd+mUpTfiZfbs7+CPjc4ob8v9d3X0MscCg@mail.gmail...
[14] https://www.postgresql.org/message-id/20200624191433.5gnqgrxfmucexldm@alap3.anarazel.de
[15] https://www.postgresql.org/message-id/CAH2-WzmD+i1pG6rc1+Cjc4V6EaFJ_qSuKCCHVnH=oruqD-zqow@mail.gmail...
[16] https://www.postgresql.org/message-id/20200703024649.GJ4107@telsasoft.com
[17] https://www.postgresql.org/message-id/CA+TgmobyV9+T-Wjx-cTPdQuRCgt1THz1mL3v1NXC4m4G-H6Rcw@mail.gmail...
[18] https://www.postgresql.org/message-id/CAA4eK1K0cgk_8hRyxsvppgoh_Z-NY+UZTcFWB2we6baJ9DXCQw@mail.gmail...
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-05 23:47 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-07 04:57 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-07 12:54 ` Re: Default setting for enable_hashagg_disk (hash_mem) David Rowley <dgrowleyml@gmail.com>
2020-07-07 19:24 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-08 01:57 ` Re: Default setting for enable_hashagg_disk (hash_mem) David Rowley <dgrowleyml@gmail.com>
@ 2020-07-08 03:26 ` Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 0 replies; 26+ messages in thread
From: Amit Kapila @ 2020-07-08 03:26 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: Peter Geoghegan <pg@bowt.ie>; Jeff Davis <pgsql@j-davis.com>; Bruce Momjian <bruce@momjian.us>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Wed, Jul 8, 2020 at 7:28 AM David Rowley <dgrowleyml@gmail.com> wrote:
>
>
> I'd really like to see this thread move forward to a solution and I'm
> not sure how best to do that. I started by reading back over both this
> thread and the original one and tried to summarise what people have
> suggested.
>
Thanks, I think this might help us in reaching some form of consensus
by seeing what most people prefer.
> I understand some people did change their minds along the way, so I
> may have made some mistakes. I could have assumed the latest mindset
> overruled, but it was harder to determine that due to the thread being
> split.
>
> For hash_mem = Justin [16], PeterG [15], Tomas [7]
> hash_mem out of scope for PG13 = Bruce [8], Andres [9]
>
+1 for hash_mem out of scope for PG13. Apart from the reasons you
have mentioned above, the other reason is if this is a way to allow
users to get a smooth experience for hash aggregates, then I think the
idea proposed by Robert is not yet ruled out and we should see which
one is better. OTOH, if we want to see this as a way to give smooth
experience for current use cases for hash aggregates and improve the
situation for hash joins as well then I think this seems to be a new
behavior which should be discussed for PG14. Having said that, I am
not saying this is not a good idea but just I don't think we should
pursue it for PG13.
> Wait for reports from users = Amit [10]
I think this is mostly inline with Bruce is intending to say ("Maybe
do nothing until we see how things go during beta"). So, probably we
can club the votes.
> Escape hatch that can be removed later when we get something better =
> Jeff [11], David [12], Pavel [13], Andres [14], Justin [1]
> Add enable_hashagg_spill = Tom [2] (I'm unclear on this proposal. Does
> it affect the planner or executor or both?)
> Maybe do nothing until we see how things go during beta = Bruce [3]
> Just let users set work_mem = Alvaro [4] (I think he changed his mind
> after Andres pointed out that changes other nodes in the plan too)
> Swap enable_hashagg for a GUC that specifies when spilling should
> occur. -1 means work_mem = Robert [17], Amit [18]
> hash_mem does not solve the problem = Tomas [6]
>
[1] - https://www.postgresql.org/message-id/CA+TgmobyV9+T-Wjx-cTPdQuRCgt1THz1mL3v1NXC4m4G-H6Rcw@mail.gmail...
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
@ 2020-07-06 10:29 ` Amit Kapila <amit.kapila16@gmail.com>
2020-07-07 03:48 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
1 sibling, 1 reply; 26+ messages in thread
From: Amit Kapila @ 2020-07-06 10:29 UTC (permalink / raw)
To: Jeff Davis <pgsql@j-davis.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Peter Geoghegan <pg@bowt.ie>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Sun, Jul 5, 2020 at 2:24 AM Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Sat, 2020-07-04 at 14:49 +0530, Amit Kapila wrote:
> > > We don't even have a user report yet of a
> > > regression compared to PG 12, or one that can't be fixed by
> > > increasing
> > > work_mem.
> > >
> >
> > Yeah, this is exactly the same point I have raised above. I feel we
> > should wait before designing any solution to match pre-13 behavior
> > for
> > hashaggs to see what percentage of users face problems related to
> > this
> > and how much is a problem for them to increase work_mem to avoid
> > regression.
>
> I agree that it's good to wait for actual problems. But the challenge
> is that we can't backport an added GUC.
>
Is it because we won't be able to edit existing postgresql.conf file
or for some other reasons?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-06 10:29 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
@ 2020-07-07 03:48 ` Jeff Davis <pgsql@j-davis.com>
2020-07-07 09:50 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 1 reply; 26+ messages in thread
From: Jeff Davis @ 2020-07-07 03:48 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Peter Geoghegan <pg@bowt.ie>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Mon, 2020-07-06 at 15:59 +0530, Amit Kapila wrote:
> I agree that it's good to wait for actual problems. But the
> > challenge
> > is that we can't backport an added GUC.
> >
>
> Is it because we won't be able to edit existing postgresql.conf file
> or for some other reasons?
Perhaps "can't" was too strong of a word, but I think it would be
unprecedented to introduce a GUC in a minor version. It could be a
source of confusion.
If others think that adding a GUC in a minor version would be
acceptable, please let me know.
Regards,
Jeff Davis
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-06 10:29 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-07 03:48 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
@ 2020-07-07 09:50 ` Amit Kapila <amit.kapila16@gmail.com>
2020-07-07 20:18 ` Re: Default setting for enable_hashagg_disk (hash_mem) Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 1 reply; 26+ messages in thread
From: Amit Kapila @ 2020-07-07 09:50 UTC (permalink / raw)
To: Jeff Davis <pgsql@j-davis.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Peter Geoghegan <pg@bowt.ie>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Tue, Jul 7, 2020 at 9:18 AM Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Mon, 2020-07-06 at 15:59 +0530, Amit Kapila wrote:
> > I agree that it's good to wait for actual problems. But the
> > > challenge
> > > is that we can't backport an added GUC.
> > >
> >
> > Is it because we won't be able to edit existing postgresql.conf file
> > or for some other reasons?
>
> Perhaps "can't" was too strong of a word, but I think it would be
> unprecedented to introduce a GUC in a minor version.
>
I don't think this is true. We seem to have introduced three new guc
variables in a 9.3.3 minor release. See the following entry in 9.3.3
release notes [1]: "Create separate GUC parameters to control
multixact freezing.... Introduce new settings
vacuum_multixact_freeze_min_age, vacuum_multixact_freeze_table_age,
and autovacuum_multixact_freeze_max_age to control when to freeze
multixacts."
Apart from this, we have asked users to not only edit postgresql.conf
file but also update system catalogs. See the fix for "Cope with the
Windows locale named "Norwegian (Bokmål)" [2] in 9.4.1 release.
There are other instances where we also suggest users to set gucs,
create new system objects (like views), perform DDL, DMLs, run REINDEX
on various indexes, etc. in the minor release.
[1] - https://www.postgresql.org/docs/release/9.3.3/
[2] - https://wiki.postgresql.org/wiki/Changes_To_Norwegian_Locale
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-06 10:29 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-07 03:48 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-07 09:50 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
@ 2020-07-07 20:18 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2020-07-07 20:37 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
0 siblings, 1 reply; 26+ messages in thread
From: Alvaro Herrera @ 2020-07-07 20:18 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; +Cc: Jeff Davis <pgsql@j-davis.com>; Bruce Momjian <bruce@momjian.us>; Peter Geoghegan <pg@bowt.ie>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On 2020-Jul-07, Amit Kapila wrote:
> I don't think this is true. We seem to have introduced three new guc
> variables in a 9.3.3 minor release.
Yeah, backporting GUCs is not a big deal. Sure, the GUC won't appear in
postgresql.conf files generated by initdb prior to the release that
introduces it. But users that need it can just edit their .confs and
add the appropriate line, or just do ALTER SYSTEM after the minor
upgrade. For people that don't need it, it would have a reasonable
default (probably work_mem, so that behavior doesn't change on the minor
upgrade).
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-06 10:29 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-07 03:48 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-07 09:50 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-07 20:18 ` Re: Default setting for enable_hashagg_disk (hash_mem) Alvaro Herrera <alvherre@2ndquadrant.com>
@ 2020-07-07 20:37 ` Peter Geoghegan <pg@bowt.ie>
2020-07-07 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 1 reply; 26+ messages in thread
From: Peter Geoghegan @ 2020-07-07 20:37 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Amit Kapila <amit.kapila16@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Bruce Momjian <bruce@momjian.us>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Tue, Jul 7, 2020 at 1:18 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Yeah, backporting GUCs is not a big deal. Sure, the GUC won't appear in
> postgresql.conf files generated by initdb prior to the release that
> introduces it. But users that need it can just edit their .confs and
> add the appropriate line, or just do ALTER SYSTEM after the minor
> upgrade.
I don't buy that argument myself. At a minimum, if we do it then we
ought to feel bad about it. It should be rare.
The fact that you can have a replica on an earlier point release
enforces the idea that it ought to be broadly compatible. Technically
users are not guaranteed that this will work, just like there are no
guarantees about WAL compatibility across point releases. We
nevertheless tacitly provide a "soft" guarantee that we won't break
WAL -- and that we won't add entirely new GUCs in a point release.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-04 09:19 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-06 10:29 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-07 03:48 ` Re: Default setting for enable_hashagg_disk (hash_mem) Jeff Davis <pgsql@j-davis.com>
2020-07-07 09:50 ` Re: Default setting for enable_hashagg_disk (hash_mem) Amit Kapila <amit.kapila16@gmail.com>
2020-07-07 20:18 ` Re: Default setting for enable_hashagg_disk (hash_mem) Alvaro Herrera <alvherre@2ndquadrant.com>
2020-07-07 20:37 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
@ 2020-07-07 20:53 ` Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 0 replies; 26+ messages in thread
From: Alvaro Herrera @ 2020-07-07 20:53 UTC (permalink / raw)
To: Peter Geoghegan <pg@bowt.ie>; +Cc: Amit Kapila <amit.kapila16@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Bruce Momjian <bruce@momjian.us>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On 2020-Jul-07, Peter Geoghegan wrote:
> On Tue, Jul 7, 2020 at 1:18 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > Yeah, backporting GUCs is not a big deal. Sure, the GUC won't appear in
> > postgresql.conf files generated by initdb prior to the release that
> > introduces it. But users that need it can just edit their .confs and
> > add the appropriate line, or just do ALTER SYSTEM after the minor
> > upgrade.
>
> I don't buy that argument myself. At a minimum, if we do it then we
> ought to feel bad about it. It should be rare.
Judging history, it's pretty clear that it *is* rare. I'm not
suggesting we do it now. I'm just contesting the assertion that it's
impossible.
> The fact that you can have a replica on an earlier point release
> enforces the idea that it ought to be broadly compatible.
A replica without hash_mem is not going to fail if the primary is
upgraded to a version with hash_mem, so I'm not sure this argument
means anything in this case. In any case, when we add WAL message types
in minor releases, users are suggested to upgrade the replicas first; if
they fail to do so, the replicas shut down when they reach a WAL point
where the primary emitted the new message. Generally speaking, we *don't*
promise that running a replica with an older minor always works, though
obviously it does work most of the time.
> Technically
> users are not guaranteed that this will work, just like there are no
> guarantees about WAL compatibility across point releases. We
> nevertheless tacitly provide a "soft" guarantee that we won't break
> WAL -- and that we won't add entirely new GUCs in a point release.
Agreed, we do provide those guarantees.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
@ 2020-07-07 17:12 ` Andres Freund <andres@anarazel.de>
2020-07-07 21:03 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
3 siblings, 1 reply; 26+ messages in thread
From: Andres Freund @ 2020-07-07 17:12 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Peter Geoghegan <pg@bowt.ie>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; David Rowley <dgrowleyml@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
Hi,
On 2020-07-03 10:08:08 -0400, Bruce Momjian wrote:
> Well, the bottom line is that we are designing features during beta.
> People are supposed to be testing PG 13 behavior during beta, including
> optimizer behavior.
I think it makes no too much sense to plan invent something like
hash_mem for v13, it's clearly too much work. That's a seperate
discussion from having something like it for v14.
> We don't even have a user report yet of a
> regression compared to PG 12, or one that can't be fixed by increasing
> work_mem.
I posted a repro, and no you can't fix it by increasing work_mem without
increasing memory usage in the whole query / all queries.
> If we add a new behavior to PG 13, we then have the pre-PG 13 behavior,
> the pre-patch behavior, and the post-patch behavior. How are people
> supposed to test all of that?
I don't really buy this as a problem. It's not like the pre-13 behaviour
would be all new. It's how PG has behaved approximately forever.
My conclusion about this topic is that I think we'll be doing our users
a disservice by not providing an escape hatch, but that I also don't
have the energy / time to fight for it further. This is a long thread
already, and I sense little movement towards a conclusion.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Re: Default setting for enable_hashagg_disk (hash_mem) Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Re: Default setting for enable_hashagg_disk (hash_mem) Bruce Momjian <bruce@momjian.us>
2020-07-07 17:12 ` Re: Default setting for enable_hashagg_disk (hash_mem) Andres Freund <andres@anarazel.de>
@ 2020-07-07 21:03 ` Peter Geoghegan <pg@bowt.ie>
0 siblings, 0 replies; 26+ messages in thread
From: Peter Geoghegan @ 2020-07-07 21:03 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Bruce Momjian <bruce@momjian.us>; Justin Pryzby <pryzby@telsasoft.com>; Tomas Vondra <tomas.vondra@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; David Rowley <dgrowleyml@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Tue, Jul 7, 2020 at 10:12 AM Andres Freund <andres@anarazel.de> wrote:
> I think it makes no too much sense to plan invent something like
> hash_mem for v13, it's clearly too much work. That's a seperate
> discussion from having something like it for v14.
Can you explain why you believe that to be the case? It seems quite
possible that there is some subtlety that I missed in grouping sets or
something like that. I would like to know the specifics, if there are
any specifics.
> My conclusion about this topic is that I think we'll be doing our users
> a disservice by not providing an escape hatch, but that I also don't
> have the energy / time to fight for it further. This is a long thread
> already, and I sense little movement towards a conclusion.
An escape hatch seems necessary. I accept that a hard disabling of
spilling at execution time meets that standard, and that may be enough
for Postgres 13. But I am concerned that an uncomfortably large
proportion of our users will end up needing this. (Perhaps I should
say a large proportion of the subset of users that might be affected
either way. You get the idea.)
I have to wonder if this escape hatch is an escape hatch for our
users, or an escape hatch for us. There is a difference.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Default setting for enable_hashagg_disk (hash_mem)
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
@ 2020-07-03 03:56 ` Peter Geoghegan <pg@bowt.ie>
1 sibling, 0 replies; 26+ messages in thread
From: Peter Geoghegan @ 2020-07-03 03:56 UTC (permalink / raw)
To: Justin Pryzby <pryzby@telsasoft.com>; +Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>; Bruce Momjian <bruce@momjian.us>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; David Rowley <dgrowleyml@gmail.com>; Jeff Davis <pgsql@j-davis.com>; Melanie Plageman <melanieplageman@gmail.com>; pgsql-hackers
On Thu, Jul 2, 2020 at 7:46 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> Thanks for putting it together, I agree that hash_mem seems to be an obvious
> "escape hatch" that generalizes existing GUCs and independently useful.
It is independently useful. It's a natural consequence of "being
honest" about work_mem and hashing.
> I feel it should same as work_mem, as it's written, and not a multiplier.
>
> And actually I don't think a lower value should be ignored: "mechanism not
> policy". Do we refuse atypical values of maintenance_work_mem < work_mem ?
I see your point, but AFAIK maintenance_work_mem was not retrofit like
this. It seems different. (Unless we add the -1 behavior, perhaps)
> I assumed that hash_mem would default to -1, which would mean "fall back to
> work_mem". We'd then advise users to increase it if they have an issue in v13
> with performance of hashes spilled to disk. (And maybe in other cases, too.)
Yeah, this kind of -1 behavior could make sense.
> I read the argument that hash tables are a better use of RAM than sort.
> However it seems like setting the default to greater than work_mem is a
> separate change than providing the mechanism allowing user to do so. I guess
> the change in default is intended to mitigate the worst possible behavior
> change someone might experience in v13 hashing, and might be expected to
> improve "out of the box" performance. I'm not opposed to it, but it's not an
> essential part of the patch.
That's true.
> In nodeHash.c, you missed an underscore:
> + * Target in-memory hashtable size is hashmem kilobytes.
Got it; thanks.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 26+ messages in thread
end of thread, other threads:[~2020-07-08 03:26 UTC | newest]
Thread overview: 26+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-07-03 02:46 Re: Default setting for enable_hashagg_disk (hash_mem) Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 02:58 ` Bruce Momjian <bruce@momjian.us>
2020-07-03 03:00 ` Bruce Momjian <bruce@momjian.us>
2020-07-03 03:35 ` Peter Geoghegan <pg@bowt.ie>
2020-07-03 14:08 ` Bruce Momjian <bruce@momjian.us>
2020-07-03 14:56 ` Justin Pryzby <pryzby@telsasoft.com>
2020-07-03 19:50 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2020-07-04 09:19 ` Amit Kapila <amit.kapila16@gmail.com>
2020-07-04 20:53 ` Jeff Davis <pgsql@j-davis.com>
2020-07-05 23:47 ` Peter Geoghegan <pg@bowt.ie>
2020-07-07 04:57 ` Jeff Davis <pgsql@j-davis.com>
2020-07-07 05:02 ` Justin Pryzby <pryzby@telsasoft.com>
2020-07-07 12:54 ` David Rowley <dgrowleyml@gmail.com>
2020-07-07 13:16 ` Pavel Stehule <pavel.stehule@gmail.com>
2020-07-07 19:24 ` Peter Geoghegan <pg@bowt.ie>
2020-07-08 01:57 ` David Rowley <dgrowleyml@gmail.com>
2020-07-08 03:26 ` Amit Kapila <amit.kapila16@gmail.com>
2020-07-06 10:29 ` Amit Kapila <amit.kapila16@gmail.com>
2020-07-07 03:48 ` Jeff Davis <pgsql@j-davis.com>
2020-07-07 09:50 ` Amit Kapila <amit.kapila16@gmail.com>
2020-07-07 20:18 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2020-07-07 20:37 ` Peter Geoghegan <pg@bowt.ie>
2020-07-07 20:53 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2020-07-07 17:12 ` Andres Freund <andres@anarazel.de>
2020-07-07 21:03 ` Peter Geoghegan <pg@bowt.ie>
2020-07-03 03:56 ` Peter Geoghegan <pg@bowt.ie>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox