| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | jacktby jacktby <jacktby(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Set enable_seqscan doesn't take effect? |
| Date: | 2023-09-28 04:26:06 |
| Message-ID: | CAKFQuwZhY1wA65gjDf10VK5SzzYe2+c_RV1SEEs_-ippuThBZg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wednesday, September 27, 2023, jacktby jacktby <jacktby(at)gmail(dot)com> wrote:
> postgres=# SET enable_seqscan = off;
> SET
> postgres=# explain select * from t;
> QUERY PLAN
> -------------------------------------------------------------------------
> Seq Scan on t (cost=10000000000.00..10000000023.60 rows=1360 width=32)
It wouldn’t cost 10billion to return the first tuple if that setting wasn’t
working.
That is the “discouragement” the documentation is referring to.
I do agree the wording in the docs could be improved since it is a bit
self-contradictory and unspecific, but it is explicitly clear a plan with
sequential scan can still be chosen even with this set to off.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-09-28 04:26:08 | Re: Requiring recovery.signal or standby.signal when recovering with a backup_label |
| Previous Message | Peter Smith | 2023-09-28 04:23:59 | Re: [PGdocs] fix description for handling pf non-ASCII characters |