From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Benjamin Coutu <ben(dot)coutu(at)zeyos(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com> |
Subject: | Re: disfavoring unparameterized nested loops |
Date: | 2022-09-30 19:04:38 |
Message-ID: | CAH2-Wz=DtkWYzJAC9B6TOUMnNZ4e=mQFDqZ12EVoK=9qkX60GA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 29, 2022 at 11:44 PM Benjamin Coutu <ben(dot)coutu(at)zeyos(dot)com> wrote:
> I think these things are orthogonal.
I agree that they're orthogonal. I just meant that execution time
strategies seem underexplored in general.
> No matter how good the cost model ever gets, we will always have degenerate cases.
Sure, but the model isn't the problem here, really -- not to me. The
problem is that the planner can in some cases choose a plan that is
inherently unreasonable, at least in practical terms. You're talking
about uncertainties. But I'm actually talking about the opposite thing
-- certainty (albeit a limited kind of certainty that applies only to
one narrow set of conditions).
It's theoretically possible that bogosort will be faster than
quicksort in some individual cases. After all, bogosort is O(n) in the
best case, which is impossible to beat! But there is no practical
sense in which bogosort could ever be better than quicksort. Having
fewer choices by just not offering inherently bad choices seems quite
unrelated to what you're talking about.
For all I know you might be onto something. But it really seems
independent to me.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-09-30 19:05:12 | Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock |
Previous Message | Andres Freund | 2022-09-30 18:59:54 | Re: EINTR in ftruncate() |