Re: a wrong index choose when statistics is out of date

From: Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>
To: Andy Fan <zhihuifan1213(at)163(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: a wrong index choose when statistics is out of date
Date: 2024-03-04 04:57:56
Message-ID: 15381eea-cbc3-4087-9d90-ab752292bd54@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/3/2024 14:01, Andy Fan wrote:
> 1. We can let the user define the column as the value is increased day by
> day. the syntax may be:
>
> ALTER TABLE x_events ALTER COLUMN created_at ALWAYS_INCREASED.
>
> then when a query like 'create_at op const', the statistics module can
> treat it as 'created_at = $1'. so the missing statistics doesn't make
> difference. Then I think the above issue can be avoided.
Let me write some words to support your efforts in that way.
I also have some user cases where they periodically insert data in large
chunks. These chunks contain 'always increased' values, and it causes
trouble each time they start an analytic query over this new data before
the analyze command.
I have thought about that issue before but invented nothing special
except a more aggressive analysis of such tables.
Your trick can work, but it needs a new parameter in pg_type and a lot
of additional code for such a rare case.
I'm looking forward to the demo patch.

--
regards,
Andrei Lepikhov
Postgres Professional

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sutou Kouhei 2024-03-04 05:11:08 Re: Make COPY format extendable: Extract COPY TO format implementations
Previous Message David Rowley 2024-03-04 04:43:50 Re: Avoid stack frame setup in performance critical routines using tail calls