On Thu, 24 Mar 2022 at 15:48, Tom Lane wrote:
>
> Simon Riggs writes:
> > On Wed, 23 Mar 2022 at 20:25, Tom Lane wrote:
> >> Do you have any objection if I rename the GUC to
> >> recursive_worktable_factor? That seems a bit clearer as to what
> >> it does, and it leaves more room for other knob
Simon Riggs writes:
> On Wed, 23 Mar 2022 at 20:25, Tom Lane wrote:
>> Do you have any objection if I rename the GUC to
>> recursive_worktable_factor? That seems a bit clearer as to what
>> it does, and it leaves more room for other knobs in the same area
>> if we decide we need any.
> None, I
On Wed, 23 Mar 2022 at 20:25, Tom Lane wrote:
>
> Simon Riggs writes:
> >> [New patch version pending]
>
> Do you have any objection if I rename the GUC to
> recursive_worktable_factor? That seems a bit clearer as to what
> it does, and it leaves more room for other knobs in the same area
> if w
Simon Riggs writes:
>> [New patch version pending]
Do you have any objection if I rename the GUC to
recursive_worktable_factor? That seems a bit clearer as to what
it does, and it leaves more room for other knobs in the same area
if we decide we need any.
regards, tom la
On Wed, 23 Mar 2022 at 18:20, Simon Riggs wrote:
> [New patch version pending]
--
Simon Riggshttp://www.EnterpriseDB.com/
recursive_worktable_estimate.v3.patch
Description: Binary data
On Wed, 23 Mar 2022 at 17:36, Tom Lane wrote:
>
> Robert Haas writes:
> > On Tue, Jan 25, 2022 at 4:44 AM Peter Eisentraut
> > wrote:
> >> On the one hand, this smells like a planner hint. But on the other
> >> hand, it doesn't look like we will come up with proper graph-aware
> >> selectivity
Robert Haas writes:
> On Tue, Jan 25, 2022 at 4:44 AM Peter Eisentraut
> wrote:
>> On the one hand, this smells like a planner hint. But on the other
>> hand, it doesn't look like we will come up with proper graph-aware
>> selectivity estimation system any time soon, so just having all graph
>>
On Tue, 22 Mar 2022 at 00:04, Andres Freund wrote:
> On 2022-03-10 17:42:14 +, Simon Riggs wrote:
> > Shall I set this as Ready For Committer?
>
> Currently this CF entry fails on cfbot:
> https://cirrus-ci.com/task/4531771134967808?logs=test_world#L1158
>
> [16:27:35.772] # Failed test 'n
Hi,
On 2022-03-10 17:42:14 +, Simon Riggs wrote:
> Shall I set this as Ready For Committer?
Currently this CF entry fails on cfbot:
https://cirrus-ci.com/task/4531771134967808?logs=test_world#L1158
[16:27:35.772] # Failed test 'no parameters missing from
postgresql.conf.sample'
[16:27:35
On Fri, 28 Jan 2022 at 14:07, Robert Haas wrote:
>
> On Tue, Jan 25, 2022 at 4:44 AM Peter Eisentraut
> wrote:
> > On the one hand, this smells like a planner hint. But on the other
> > hand, it doesn't look like we will come up with proper graph-aware
> > selectivity estimation system any time
On Tue, Jan 25, 2022 at 4:44 AM Peter Eisentraut
wrote:
> On the one hand, this smells like a planner hint. But on the other
> hand, it doesn't look like we will come up with proper graph-aware
> selectivity estimation system any time soon, so just having all graph
> OLTP queries suck until then
On Tue, 25 Jan 2022 at 14:44, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 31.12.21 15:10, Simon Riggs wrote:
> >> The factor 10 is a reasonably safe assumption and helps avoid worst
> >> case behavior in bigger graph queries. However, the factor 10 is way
> >> too large for m
On 31.12.21 15:10, Simon Riggs wrote:
The factor 10 is a reasonably safe assumption and helps avoid worst
case behavior in bigger graph queries. However, the factor 10 is way
too large for many types of graph query, such as where the path
through the data is tight, and/or the query is written to
> The factor 10 should not be hardcoded in the planner, but should be
settable, just as cursor_tuple_fraction is.
I feel considerably out of my depth here, but I like the idea of a working
table size multiplier GUC, given the challenges of predicting the number of
iterations (and any adjustments t
On Wed, 27 Oct 2021 at 15:58, Simon Riggs wrote:
> The poor performance is traced to the planner cost estimates for
> recursive queries. Specifically, the cost of the recursive arm of the
> query is evaluated based upon both of these hardcoded assumptions:
>
> 1. The recursion will last for 10 lo
I've been investigating the poor performance of a WITH RECURSIVE
query, which I've recreated with test data.
The first thing was to re-write the query, which helped improve
performance by about 30%, but the plan was still very bad. With a
small patch I've been able to improve performance by about
16 matches
Mail list logo
