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
> >
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,
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
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
On 29/08/2023, David Rowley wrote:
> On Tue, 29 Aug 2023 at 19:40, Philippe Pepiot wrote:
> > I'm trying to implement some range partitioning on timeseries data. But it
> > looks some queries involving date_trunc() doesn't make use of partitioning.
> >
> > BEGIN;
> > CREATE TABLE test (
> >
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
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
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
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 keep the experiment clean,
I ran it several times, first a couple of times explain analyze, then a
couple of times the query itself:
# PREPARE the_query (varchar) AS
SELECT
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)
10 matches
Mail list logo
