On Fri, 25 Apr 2025 at 03:06, Laurenz Albe wrote:
>
> On Fri, 2025-04-25 at 01:41 +1200, David Rowley wrote:
> > The 79.3 seconds is the total time spent doing reads for all parallel
> > workers. 52.6 seconds is the wall clock time elapsed to execute the
> > query.
>
&g
On Tue, 29 Apr 2025 at 01:54, Tom Lane wrote:
> I do actually have some sympathy for your proposal after thinking
> about it a bit more, but the argument I would use is "the behavior
> of the ON CONFLICT UPDATE SET list should be as much as possible like
> the behavior of an ordinary UPDATE's SET
On Wed, 19 Feb 2025 at 09:56, dfgpostgres wrote:
> So I want the avg of the max of the set where id=1 (5.0), where id=2 (6.0),
> where id=3 (8.0) ~= 6.33...
>
> I tried this...
>
> select
> avg(x.maxsz)
>from
> dvm.dvm_events d,
>
On Sat, 29 Mar 2025 at 10:30, Renan Alves Fonseca
wrote:
> Currently, in the SQL function path the plan is always generic. The
> planner ignores the function arguments. The plan_cache_mode setting
> has no effect in this path.
>
> I agree that the docs should be more explicit about this. There is
On Thu, 3 Apr 2025 at 18:07, Tom Lane wrote:
> A simple-minded approach could be to just be pessimistic, and
> increase our estimate of how many rows would need to be scanned as a
> consequence of noticing that the columns have significant correlation.
> The shape of that penalty function would be
On Thu, 3 Apr 2025 at 16:24, Manikandan Swaminathan
wrote:
> Since you mentioned the planner not knowing about the correlation between the
> columns, I’m curious, why doesn’t making a multivariate statistic make a
> difference?
>
>
> CREATE STATISTICS col_a_col_b_stats (dependencies) ON col_a, c
On Thu, 8 May 2025 at 22:57, Karsten P wrote:
> i'm sorry i didn't check that first. it just won't work in my real-life
> example.
> though each part of the query is using an index-scan it is than using a
> 'normal' append
> instead of a merge-append, but i don't know why.
You could try:
SET ena
On Wed, 4 Jun 2025 at 07:22, Matthew Tice wrote:
> Tue 03 Jun 2025 07:13:11 PM UTC (every 1s)
> n_dead_tup | 5038
> autoanalyze_count | 3078
> Tue 03 Jun 2025 07:13:12 PM UTC (every 1s)
> n_dead_tup | 1290579
> autoanalyze_count | 3079
> I don't understand where this large
On Wed, 23 Jul 2025 at 03:18, Peter J. Holzer wrote:
>
> PostgreSQL version 17.5 on Ubuntu 24.04 (PGDG build).
> -> Merge Left Join (cost=4613.25..7180.30 rows=8357
> width=136) (actual time=222.037..292242.701 rows=40460 loops=1)
> Merge Cond: (ns.nspname =
301 - 309 of 309 matches
Mail list logo
