Obsolete comment in tidpath.c
I think "best_inner_indexscan()" in the following comment in tidpath.c
is obsolete.
* There is currently no special support for joins involving CTID; in
* particular nothing corresponding to best_inner_indexscan(). Since it's
* not very useful to store TIDs of one table in another table, there
* doesn't seem to be enough use-case to justify adding a lot of code
* for that.
How about s/best_inner_indexscan()/parameterized scans/?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Oct 5, 2015 at 3:05 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:
I think "best_inner_indexscan()" in the following comment in tidpath.c
is obsolete.* There is currently no special support for joins involving CTID; in
* particular nothing corresponding to best_inner_indexscan(). Since it's
* not very useful to store TIDs of one table in another table, there
* doesn't seem to be enough use-case to justify adding a lot of code
* for that.How about s/best_inner_indexscan()/parameterized scans/?
I'm not sure that's altogether clear.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Mon, Oct 5, 2015 at 3:05 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:I think "best_inner_indexscan()" in the following comment in tidpath.c
is obsolete.* There is currently no special support for joins involving CTID; in
* particular nothing corresponding to best_inner_indexscan(). Since it's
* not very useful to store TIDs of one table in another table, there
* doesn't seem to be enough use-case to justify adding a lot of code
* for that.How about s/best_inner_indexscan()/parameterized scans/?
I'm not sure that's altogether clear.
Probably consider_index_join_clauses() is the closest current equivalent.
However, it may not be such a great idea to have this comment referencing
a static function in another file, as it wouldn't occur to people to look
here when rewriting indxpath.c. (Ahem.)
Perhaps "in particular, no ability to produce parameterized paths here".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015/10/07 7:01, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Mon, Oct 5, 2015 at 3:05 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:I think "best_inner_indexscan()" in the following comment in tidpath.c
is obsolete.* There is currently no special support for joins involving CTID; in
* particular nothing corresponding to best_inner_indexscan(). Since it's
* not very useful to store TIDs of one table in another table, there
* doesn't seem to be enough use-case to justify adding a lot of code
* for that.How about s/best_inner_indexscan()/parameterized scans/?
I'm not sure that's altogether clear.
Probably consider_index_join_clauses() is the closest current equivalent.
However, it may not be such a great idea to have this comment referencing
a static function in another file, as it wouldn't occur to people to look
here when rewriting indxpath.c. (Ahem.)Perhaps "in particular, no ability to produce parameterized paths here".
Works for me.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers