On Fri, Feb 7, 2025 at 2:05 AM Jon Emord wrote:
> My expectation is that the following two queries would have roughly the same
> performance.
> They both use the same index only scans and return the same 100 rows of data.
> The main difference I see in the explain output is that the row wise
> c
On 9/10/2025 10:52, Frits Jalvingh wrote:
I do not understand why the simpler query (without the self join)
produces a plan that seems to require nested loops, I hope someone can
explain.
It seems obvious. You have a join clause:
'enheid.id_h_eenheid = huurovereenkomst_s._l_eenheid'
One side o
On Friday, October 10, 2025, wrote:
> Looking for help on storing and retrieving the personal data as masked.
> Any references and implementation details would help
>
Don’t reply to existing threads with unrelated stuff. Just send an email
to begin your own thread. And choose an appropriate pl
On 9/23/25 12:43, Andrei Lepikhov wrote:
But is it the same for the 'distinct' statistics? It seems you should
love it - the number of groups in GROUP-BY, DISTINCT, and even HashJoin
should be estimated more precisely, no?
I think it has more potential, and I would love to use this weapon,
On 23/9/2025 15:31, Frédéric Yhuel wrote:
To get back to the topic of partitioned statistics, do you know if SQL
Server is smart enough to handle this case [1] that we discussed last
year? (with filtered statistics)
[1] https://www.postgresql.org/message-id/flat/b860c71a-7cab-4d88-
ad87-8c1f2
On 13/10/2025 16:55, Tom Lane wrote:
Andrei Lepikhov writes:
On 25/9/2025 12:41, Frédéric Yhuel wrote:
So, on SQL Server, you can do this:
CREATE STATISTICS FooStats ON foo (ackid, crit) WHERE crit = 'WARNING';
Nice! Thanks for the report. I think the only reason why Postgres
doesn't have i
