Re: Planning time is time-consuming

> On 15 Dec 2023, at 22:49, Merlin Moncure wrote: > > On Mon, Sep 11, 2023 at 11:07 PM David Rowley > wrote: >> Snip >> I took a few minutes to reverse engineer the tables in question (with >> assistance from an AI bot) and ran the query in question. >> Unsurprisi

Re: Planning time is time-consuming

On Mon, Sep 11, 2023 at 11:07 PM David Rowley wrote: > On Tue, 12 Sept 2023 at 02:27, Tom Lane wrote: > > > > David Rowley writes: > > > I'm not sure if you're asking for help here because you need planning > > > to be faster than it currently is, or if it's because you believe that > > > plann

Re: Planning time is time-consuming

On Tue, 12 Sept 2023 at 02:27, Tom Lane wrote: > > David Rowley writes: > > I'm not sure if you're asking for help here because you need planning > > to be faster than it currently is, or if it's because you believe that > > planning should always be faster than execution. If you think the > > la

Re: Planning time is time-consuming

Hi Mikhail. Postgresql version: 15.3 (Debian 15.3-1.pgdg110+1) on x86_64-pc-linux-gnu, > compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit > And just in case it matters, this is an experimental setup, so Postgresql > running in Docker. > Are you using the official Docker Postgres image, s

Re: Planning time is time-consuming

David Rowley writes: > I'm not sure if you're asking for help here because you need planning > to be faster than it currently is, or if it's because you believe that > planning should always be faster than execution. If you think the > latter, then you're mistaken. Yeah. I don't see anything par

Re: Planning time is time-consuming

Any statement that is executed has to go through the 4 stages of query execution: - parse - rewrite - plan - execute The execute phase is the phase that mostly is the focus on, and is the phase in which normally is spent the most time. In the postgres backend main loop, there are multiple ways

Re: Planning time is time-consuming

On Mon, 11 Sept 2023 at 21:54, Mikhail Balayan wrote: > Could it be a regression? I'll check it on PG14 when I get a chance. I'm not sure if you're asking for help here because you need planning to be faster than it currently is, or if it's because you believe that planning should always be faste

Re: Planning time is time-consuming

On Mon, 11 Sept 2023 at 18:16, Laurenz Albe wrote: > Also, there are quite a lot of indexes on "test_db_bench_1". On a test > database, drop some > indexes and see if that makes a difference. Yeah, I count 3 that either have the key columns as some prefix of another index or are just a duplicat

Re: Fwd: Planning time is time-consuming

On Mon, 2023-09-11 at 12:57 +0800, Mikhail Balayan wrote: > Thanks for the idea. I was surprised to find that this is not the way it > works and the planning time remains the same. To benefit from the speed gains of a prepared statement, you'd have to execute it at least seven times. If a gener

Fwd: Planning time is time-consuming

('4c79c1c5-21ae-45a0-8734-75d67abd0330'); id | tenant_id +--- (0 rows) Time: 1.311 ms # EXECUTE the_query('4c79c1c5-21ae-45a0-8734-75d67abd0330'); id | tenant_id +--- (0 rows) Time: 1.230 ms -- Mikhail On Mon, 11 Sept 2023 at 09:23, Anupam b wrote:

Fwd: Planning time is time-consuming

Hi Laurenz, My bad, I forgot to write that I tried vacuum too, but it didn't help. To demonstrate the result, I did it again: # vacuum (analyze, verbose) test_db_bench_1; INFO: vacuuming "perfkit.public.test_db_bench_1" INFO: launched 2 parallel vacuum workers for index cleanup (planned: 2) INF

Re: Planning time is time-consuming

On 11 September 2023 03:15:43 CEST, Laurenz Albe wrote: >On Fri, 2023-09-08 at 18:51 +0800, Mikhail Balayan wrote: >> I have three tables: >>     - test_db_bench_1 >>     - test_db_bench_tenants >>     - test_db_bench_tenant_closure >> >> And the query to join them: >> SELECT "test_db_bench_1

Re: Planning time is time-consuming

pgsql-performa...@postgresql.org Subject: Re: Planning time is time-consuming On Fri, 2023-09-08 at 18:51 +0800, Mikhail Balayan wrote: > I have three tables: > - test_db_bench_1 > - test_db_bench_tenants > - test_db_bench_tenant_closure > > And the quer

Re: Planning time is time-consuming

On Fri, 2023-09-08 at 18:51 +0800, Mikhail Balayan wrote: > I have three tables: >     - test_db_bench_1 >     - test_db_bench_tenants >     - test_db_bench_tenant_closure > > And the query to join them: > SELECT "test_db_bench_1"."id" id, "test_db_bench_1"."tenant_id" >   FROM "test_db_bench_1" >

Planning time is time-consuming

Hello, I have three tables: - test_db_bench_1 - test_db_bench_tenants - test_db_bench_tenant_closure And the query to join them: SELECT "test_db_bench_1"."id" id, "test_db_bench_1"."tenant_id" FROM "test_db_bench_1" JOIN "test_db_bench_tenants" AS "tenants_child" ON (("tenants_chil