Thread: [PATCH] psql visibility clarification patch
Attached is a patch that I would like to submit for discussion. The goal of this patch is a solution to the issue that I found concerning table visibility. The problem with the way psql currently lists tables in a database is that it limits it to only the tables currently in the search path. If it isn't visible, then you will never see the table. This can cause problems for a person that is trying to learn a database for the first time or something along those lines unless they are familiar with the pg_catalog. I think a better solution to handling the issue of visibility is shown below. It will list all of the tables of the database and show another column to give indication of the visibility of the table. eecs=> \d List of relations Schema | Name | Type | Visible | Owner ------------+------------------------+----------+---------+-------term_029 | schedule | table | f | dbaterm_029 | schedule_preceptor | table | f | dbaterm_029 | schedule_preceptor_seq | sequence | f | dbaterm_029 | schedule_seq | sequence | f | dbaterm_029 | schedule_student | table |f | dbaterm_029 | schedule_student_seq | sequence | f | dbaterm_032 | schedule | table | t | dbaterm_032 | schedule_preceptor | table | t | dbaterm_032 | schedule_preceptor_seq | sequence| t | dbaterm_032 | schedule_seq | sequence | t | dbaterm_032 | schedule_student | table | t | dbaterm_032 | schedule_student_seq | sequence | t | dba -- //========================================================\\ || D. Hageman <dhageman@dracken.com> || \\========================================================//
"D. Hageman" <dhageman@dracken.com> writes: > The goal of this patch is a solution to the issue that I found concerning > table visibility. The problem with the way psql currently lists tables in > a database is that it limits it to only the tables currently in the search > path. That's the intended behavior. I don't think that "\dt foo" should show any tables other than the same "foo" you'd get from an unqualified reference to "foo". If you want to know about foos that are not in your search path, you can do "\dt *.foo". Your proposed patch essentially eliminates the distinction between \dt foo and \dt *.foo. This doesn't seem like a step forward to me. Perhaps what's really needed is a documentation patch explaining when to use each? regards, tom lane
1. the following query is so slow, after 12 hours, I kill it - delete from doc where cdi in (select cdi from doc_b1); doc_b1 records = 40000 doc records = 5000000 cdi are indexed in both table. 2. I rewrite the above task in plpgsql, it takes 10 secs to finish. why psql subquery is not smarter enough to use indexes if obviously? johnl
"John Liu" <johnl@emrx.com> writes: > why psql subquery is not smarter enough to use > indexes if obviously? IN is smarter as of CVS tip. regards, tom lane