Re: inequality predicate not pushed down in JOIN?

While applying transitivity to non-equality conditions is less frequently beneficial than applying it to equality conditions, it can be very helpful, especially with third party apps and dynamically changing data. One possible implementation to avoid the mentioned overhead would be to mark the int

Re: inequality predicate not pushed down in JOIN?

Cool! Thanks for the speedy reply, link, and summary! I'm not sure how I missed this, but apologies for the noise. -Paul- On Thu, Jul 11, 2024 at 4:49 PM Andrei Lepikhov wrote: > On 12/7/2024 06:31, Paul George wrote: > > In the example below, I noticed that the JOIN predicate "t1.a<1" is not >

Re: inequality predicate not pushed down in JOIN?

On 12/7/2024 06:31, Paul George wrote: In the example below, I noticed that the JOIN predicate "t1.a<1" is not pushed down to the scan over "t2", though it superficially seems like it should be. It has already discussed at least couple of years ago, see [1]. Summarising, it is more complicated

inequality predicate not pushed down in JOIN?

Hey! [version: PostgreSQL 16.3] In the example below, I noticed that the JOIN predicate "t1.a<1" is not pushed down to the scan over "t2", though it superficially seems like it should be. create table t as (select 1 a); analyze t; explain (costs off) select * from t t1 join t t2 on t1.a=t2.a and

Re: How to solve my slow disk i/o throughput during index scan

On 11/7/2024 21:59, FREYBURGER Simon (SNCF VOYAGEURS / DIRECTION GENERALE TGV / DM RMP YIELD MANAGEMENT) wrote: Hello, and thank you again for your example ! Sorry for my late answer, I was working on a patch for our requests. I am though not completely understanding what is happening. Here is

Re: How to solve my slow disk i/o throughput during index scan

On 11/7/2024 22:09, FREYBURGER Simon (SNCF VOYAGEURS / DIRECTION GENERALE TGV / DM RMP YIELD MANAGEMENT) wrote: Is it possible to parallelize the scans during the modify step ? Temporary tables can't be used inside a query with parallel workers involved, because such table is local for single pr

Re: How to solve my slow disk i/o throughput during index scan

On Thursday, July 11, 2024, FREYBURGER Simon (SNCF VOYAGEURS / DIRECTION GENERALE TGV / DM RMP YIELD MANAGEMENT) wrote: > Also, It might not be related, but I have suspiciously similar slow reads > when I am inserting in database, could it be related ? > I’m using a 3 steps process to insert my l

RE: How to solve my slow disk i/o throughput during index scan

Also, It might not be related, but I have suspiciously similar slow reads when I am inserting in database, could it be related ? See e.g. : https://explain.dalibo.com/plan/43d37de5870e1651 The table I am inserting into looks like : -- public."F_TDOJ_SC_HIST_2" definition -- Drop table -- DROP

RE: How to solve my slow disk i/o throughput during index scan

Hello, and thank you again for your example ! Sorry for my late answer, I was working on a patch for our requests. I am though not completely understanding what is happening. Here is a plan of a query where I splitted the calls with OR as you suggested, what seemed to have enabled parallel sca