| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: should we have a fast-path planning for OLTP starjoins? |
| Date: | 2025-11-28 18:57:14 |
| Message-ID: | CA+TgmoZmiK=ASNh6iXxqcf4+5CasJehJDy_Rt4vN89_6NLzGRA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 26, 2025 at 1:30 PM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
> > In my experience, restriction clauses on dimension tables are very common.
>
> Sure, but does that imply the inverse case (dimensions without non-join
> restrictions) are not? I'm not sure.
Obviously that depends on a lot of things, and I don't completely
understand what the patch does and doesn't do. But, I think it would
be sad to implement an optimization that falls over catastrophically
when such restriction clauses are present. For example, a long time
ago, I used to build web applications. Twenty, even thirty table joins
were common. There certainly wouldn't be a restriction clause on every
dimension table, but it would be an unusual situation if there were NO
restriction clauses on ANY dimension table. It's maybe also worth
mentioning that in those applications, it wasn't always a pure star
join: one central fact table would join to a bunch of codes tables,
but also very often to some other fact tables that had their own codes
tables. Point being that optimizations like this can be shown to have
a LOT of value in individual test cases even if the circumstances in
which they can be applied are very restricted, but lifting some of
those restrictions can enormously expand the number of real-world
cases to which they apply. My intuition is that a smaller gain on a
larger class of queries will win us more praise than the reverse.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2025-11-28 19:08:12 | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
| Previous Message | Mihail Nikalayeu | 2025-11-28 18:42:31 | Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY |