Re: Question about use_physical_tlist() which is applied on Scan path
| От | 油屋 |
|---|---|
| Тема | Re: Question about use_physical_tlist() which is applied on Scan path |
| Дата | |
| Msg-id | CAPt2h2YE2Cwp5aZG+uODu2y2ZJLZsWBVBm1WAo2+8xPhctJaxw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Question about use_physical_tlist() which is applied on Scan path (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Список | pgsql-hackers |
I had the same question recently. In addition, I looked at the results of tpch which scale factor is 1 ran on postgres REL_15_STABLE and observed no performance improvement from physical tlist. To be specific, I run two versions of tpch, one with physical tlist enabled and one with physical tlist disabled. The performance improvement of some queries in the former was less than 5%, some queries performed worse than latter, and I think this is a normal range of performance fluctuations which was not caused by physical tlist. I have read the relevant commits, maybe because of my carelessness, I did not find the test queries corresponding to physical tlist. Are there any test queries of physical tlist?
Thanks
Alvaro Herrera <alvherre@alvh.no-ip.org> 于2023年7月26日周三 18:16写道：
On 2023-Jul-26, Jian Guo wrote:
> It looks the columns besides `ps_supplycost` and `ps_availqty` are not
> necessary, but fetched from tuples all at once. For the row-based
> storage such as heap, it looks fine, but for column-based storage, it
> would result into unnecessary overhead and impact performance. Is
> there any plan to optimize here?
I suppose that, at some point, it is going to have to be the table AM
the one that makes the decision. That is, use_physical_tlist would have
to involve some new flag in path->parent->amflags to determine whether
to skip using a physical tlist. Right now, we don't have any columnar
stores, so there's no way to verify an implementation. If you do have a
columnar store implementation, you're welcome to share it.
--
Álvaro Herrera PostgreSQL Developer
"I am amazed at [the pgsql-sql] mailing list for the wonderful support, and
lack of hesitasion in answering a lost soul's question, I just wished the rest
of the mailing list could be like this." (Fotis)
(http://archives.postgresql.org/pgsql-sql/2006-06/msg00265.php)
В списке pgsql-hackers по дате отправления: