Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500

Поиск
Список
Период
Сортировка
От Alexander Lakhin
Тема Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500
Дата
Msg-id 608a4886-6c60-0f9e-97d5-591256bd4150@gmail.com
обсуждение исходный текст
Ответ на Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hello Tom and Richard,

17.11.2023 22:42, Tom Lane wrote:
> OK.  I pushed the patch after a bit more review: we can simplify
> things some more by using the subroot->parse querytree for all
> tests.  After the previous refactoring, it wasn't buying us anything
> to do some initial tests with the raw querytree.  (The original
> idea of that, I believe, was to avoid doing find_base_rel if we
> could; but now that's not helpful.)

Please look at the following query:
CREATE TABLE t(i int);
INSERT INTO t VALUES (1);
VACUUM ANALYZE t;

WITH ir AS (INSERT INTO t VALUES (2) RETURNING i)
SELECT * FROM ir WHERE i = 2;

which produces ERROR:  no relation entry for relid 1
starting from f7816aec2.

Best regards,
Alexander



В списке pgsql-hackers по дате отправления:

Предыдущее
От: jian he
Дата:
Сообщение: Re: Change GUC hashtable to use simplehash?
Следующее
От: Bertrand Drouvot
Дата:
Сообщение: Re: verify predefined LWLocks have entries in wait_event_names.txt