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
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 |