On Thu, 18 Sept 2025 at 23:55, Andrei Lepikhov wrote:
> It looks like a makeshift solution. By implementing a callback, we could
> elevate 'interrupter' to a first-class feature, enabling us to monitor
> the state of the entire query tree (it is especially cool in EXPLAIN
> ANALYZE mode when we ma
Thanks David,
Le 18/09/2025 à 09:20, David Rowley a écrit :
Yes. Since *all* records of "oeu" are required and they're not
required in any particular order, then Seq Scan should be the fastest
way to access those records.
Ok but then why is it doing it on the AD table? Is it because of the
nu
=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Yhuel?= writes:
> On 9/17/25 16:41, Tom Lane wrote:
>> =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Yhuel?= writes:
>>> 2) the number of estimated rows is completely off in the second EXPLAIN,
>>> whereas the planner could easily use the statistics of foo_f_idx.
>> Hmm, not sure abo
On Thu, 18 Sept 2025 at 18:36, Jean-Christophe BOGGIO
wrote:
> Insert on copyrightad (cost=613790.59..4448045.97 rows=0 width=0)
> -> Merge Join (cost=613790.59..4448045.97 rows=84972138 width=328)
> Merge Cond: (((c.imcompid)::numeric) = ip.sipa_ip_code)
> -> Sort (cost=357
Jehan-Guillaume de Rorthais writes:
> On a fresh instance from HEAD with its default configuration, it shows:
> Index Scan using foo_s_idx on foo (cost=0.29..8.39 rows=3 width=13)
> Index Cond: (s(crit, ackid) = true)
> It seems statistics shown in "pg_stats" view for function "s()" a
Em qui., 18 de set. de 2025 às 13:40, Tom Lane escreveu:
> I wrote:
> > Sigh ... so the answer is this used to work (since commit 39df0f150)
> > and then I carelessly broke it in commit a391ff3c3. If you try this
> > test case in versions 9.5..11 you get a spot-on rowcount estimate.
> > Serves m
I wrote:
> Sigh ... so the answer is this used to work (since commit 39df0f150)
> and then I carelessly broke it in commit a391ff3c3. If you try this
> test case in versions 9.5..11 you get a spot-on rowcount estimate.
> Serves me right for not having a test case I guess, but I'm astonished
> that
Hi there,
I think this discussion has a nice solution, thank you!
However, while poking around this issue yesterday, we also found something
surprising between estimated rows and costs when using a function. Bellow the
scenario to apply on top of Frederic's one to quickly expose the weirdness:
On 18/9/2025 13:35, David Rowley wrote:
On Thu, 18 Sept 2025 at 19:55, Andrei Lepikhov wrote:
Imagine if we had a hook within the ExecProcNode. In that scenario, we
could create a trivial extension that would stop the query after, let's
say, 10 minutes of execution and display the current state
On 18/9/2025 09:20, David Rowley wrote:
On Thu, 18 Sept 2025 at 18:36, Jean-Christophe BOGGIO
If it still takes a long time, you might try SET enable_mergejoin = 0;
and run the EXPLAIN ANALYZE SELECT .. part. That'll at least give us
more accurate row counts of what we're actually working with.T
On Thu, 18 Sept 2025 at 19:55, Andrei Lepikhov wrote:
> Imagine if we had a hook within the ExecProcNode. In that scenario, we
> could create a trivial extension that would stop the query after, let's
> say, 10 minutes of execution and display the current state. This would
> give us more reliable
On Thu, 18 Sept 2025 at 19:45, Jean-Christophe BOGGIO
wrote:
> Ok but then why is it doing it on the AD table? Is it because of the
> number of rows?
It's hard to tell as I don't have a clear view on which columns are
from which tables. Perhaps "ad" can Index Only Scan because all of
the columns
12 matches
Mail list logo
