public inbox for [email protected]  

help / color / mirror / Atom feed

From: Peter Eisentraut <[email protected]>
To: Simon Riggs <[email protected]>
To: PostgreSQL Hackers <[email protected]>
Subject: Re: Parameter for planner estimate of recursive queries
Date: Tue, 25 Jan 2022 10:44:21 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CANbhV-HGhrkoF9BoHXScVZY8_HnBoHzGRQU15E6iPaF6ij0Cmw@mail.gmail.com>
References: <CANbhV-EuaLm4H3g0+BSTYHEGxJj3Kht0R+rJ8vT57Dejnh=_nA@mail.gmail.com>
	<CANbhV-HGhrkoF9BoHXScVZY8_HnBoHzGRQU15E6iPaF6ij0Cmw@mail.gmail.com>

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 prune bushy
>> graphs, e.g. shortest path queries. The factor 10 should not be
>> hardcoded in the planner, but should be settable, just as
>> cursor_tuple_fraction is.
> If you think this should be derived without parameters, then we would
> want a function that starts at 1 for 1 input row and gets much larger
> for larger input. The thinking here is that Graph OLTP is often a
> shortest path between two nodes, whereas Graph Analytics and so the
> worktable will get much bigger.

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 because the planner hint is hardcoded 
doesn't seem like a better solution.  So I think this setting can be ok. 
  I think the way you have characterized it makes sense, too: for graph 
OLAP, you want a larger value, for graph OLTP, you want a smaller value.

view thread (14+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Parameter for planner estimate of recursive queries
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox