On Thu, Jul 30, 2020 at 6:40 PM Justin Pryzby wrote:
> Feel free to close it out. I'm satisfied that we've had a discussion about
> it.
Closed it out.
--
Peter Geoghegan
On Thu, Jul 30, 2020 at 6:39 PM James Coleman wrote:
> I very much do not like this approach, and I think it's actually
> fundamentally wrong, at least for the memory check. Quicksort is not the only
> option that uses memory. For now, there's only one option that spills to disk
> (external mer
On Thu, Jul 30, 2020 at 06:33:32PM -0700, Peter Geoghegan wrote:
> On Thu, Jul 30, 2020 at 5:22 PM Justin Pryzby wrote:
> > Because filtering out zero values is exactly what's intended to be avoided
> > for
> > nontext output.
> >
> > I think checking whether the method was used should result in
On Thu, Jul 30, 2020 at 8:22 PM Justin Pryzby wrote:
> On Wed, Jul 29, 2020 at 09:18:44PM -0700, Peter Geoghegan wrote:
> > On Wed, Jul 29, 2020 at 9:05 PM Justin Pryzby
> wrote:
> > > So my 2ndary suggestion is to conditionalize based on the method
> rather than
> > > value of space used.
> >
>
On Thu, Jul 30, 2020 at 5:22 PM Justin Pryzby wrote:
> Because filtering out zero values is exactly what's intended to be avoided for
> nontext output.
>
> I think checking whether the method was used should result in the same output,
> without the literal check for zero value (which itself sets a
On Wed, Jul 29, 2020 at 09:18:44PM -0700, Peter Geoghegan wrote:
> On Wed, Jul 29, 2020 at 9:05 PM Justin Pryzby wrote:
> > So my 2ndary suggestion is to conditionalize based on the method rather than
> > value of space used.
>
> What's the advantage of doing it that way?
Because filtering out z
On Wed, Jul 29, 2020 at 9:05 PM Justin Pryzby wrote:
> So my 2ndary suggestion is to conditionalize based on the method rather than
> value of space used.
What's the advantage of doing it that way?
--
Peter Geoghegan
On Wed, Jul 29, 2020 at 08:35:08PM -0700, Peter Geoghegan wrote:
> AFAICT sort (and IncrSort) don't fail to show a field value if it is
> zero. Rather, they consistently show "space used" (in non-text
> format), which can be either memory or disk space. Technically they
> don't violate the letter o
On Mon, Jul 27, 2020 at 8:36 PM Justin Pryzby wrote:
> I don't know of a guideline for text format, but the issues I've raised for
> HashAgg and IncrSort are based on previous commits which change to "show field
> even if its value is zero" for non-text format:
But the non-text format for IncrSor
On Mon, 27 Jul 2020 at 14:54, Justin Pryzby wrote:
>
> On Mon, Jul 27, 2020 at 10:48:45AM +1200, David Rowley wrote:
> > On Wed, 1 Jul 2020 at 18:46, Jeff Davis wrote:
> > >
> > > On Tue, Jun 30, 2020, 7:04 PM David Rowley wrote:
> > >>
> > >> Does anyone have any objections to that being change
On Tue, 28 Jul 2020 at 15:21, Peter Geoghegan wrote:
> Separately, I wonder what your opinion is about what should happen for
> the partial sort related EXPLAIN ANALYZE format open item, described
> here:
>
> https://www.postgresql.org/message-id/flat/20200619040358.GZ17995%40telsasoft.com#b20bd20
On Tue, 28 Jul 2020 at 15:01, Justin Pryzby wrote:
>
> On Tue, Jul 28, 2020 at 12:54:35PM +1200, David Rowley wrote:
> > On Mon, 27 Jul 2020 at 14:54, Justin Pryzby wrote:
> > > It's unrelated to hashAgg vs hashJoin, but I also noticed that this is
> > > shown
> > > only conditionally:
> > >
> >
On Mon, Jul 27, 2020 at 08:20:45PM -0700, Peter Geoghegan wrote:
> On Mon, Jul 27, 2020 at 5:54 PM David Rowley wrote:
> > hmm. I'm not sure. I think this should follow the same logic as what
> > "Disk Usage" follows, and right now we don't show Disk Usage unless we
> > spill. Since we only use pa
On Mon, Jul 27, 2020 at 5:54 PM David Rowley wrote:
> hmm. I'm not sure. I think this should follow the same logic as what
> "Disk Usage" follows, and right now we don't show Disk Usage unless we
> spill. Since we only use partitions when spilling, I don't think it
> makes sense to show the estima
On Tue, Jul 28, 2020 at 12:54:35PM +1200, David Rowley wrote:
> On Mon, 27 Jul 2020 at 14:54, Justin Pryzby wrote:
> > It's unrelated to hashAgg vs hashJoin, but I also noticed that this is shown
> > only conditionally:
> >
> > if (es->format != EXPLAIN_FORMAT_TEXT)
> > {
> >
On Mon, 27 Jul 2020 at 14:54, Justin Pryzby wrote:
> It's unrelated to hashAgg vs hashJoin, but I also noticed that this is shown
> only conditionally:
>
> if (es->format != EXPLAIN_FORMAT_TEXT)
> {
> if (es->costs && aggstate->hash_planned_partitions > 0)
>
On Mon, Jul 27, 2020 at 10:48:45AM +1200, David Rowley wrote:
> On Wed, 1 Jul 2020 at 18:46, Jeff Davis wrote:
> >
> > On Tue, Jun 30, 2020, 7:04 PM David Rowley wrote:
> >>
> >> Does anyone have any objections to that being changed?
> >
> > That's OK with me. By the way, I'm on vacation and will
On Wed, 1 Jul 2020 at 18:46, Jeff Davis wrote:
>
> On Tue, Jun 30, 2020, 7:04 PM David Rowley wrote:
>>
>> Does anyone have any objections to that being changed?
>
> That's OK with me. By the way, I'm on vacation and will catch up on these
> HashAgg threads next week.
(Adding Justin as I know h
On Tue, Jun 30, 2020, 7:04 PM David Rowley wrote:
> Does anyone have any objections to that being changed?
>
That's OK with me. By the way, I'm on vacation and will catch up on these
HashAgg threads next week.
Regards,
Jeff Davis
Hi,
While working on 40efbf870 I noticed that when performing a Hash Join
that we always start out by setting nbatch to 1. That seems
reasonable as it's hard to imagine being able to complete any non-zero
amount of work in fewer than 1 batch.
In the HashAgg case, since 40efbf870, we'll display:
20 matches
Mail list logo
