Re: Set enable_seqscan doesn't take effect?

2023-09-28 Thread Bruce Momjian
On Thu, Sep 28, 2023 at 03:38:28PM +0800, jacktby jacktby wrote:
> > You start several threads a week, often clearly not having done much, if 
> > any,
> > prior research. Often even sending the same question to multiple lists. It
> > should not be hard to find an explanation for the behaviour you see here.
> > 
> > pgsql-hackers isn't a "do my work for me service". We're hacking on
> > postgres. It's fine to occasionally ask for direction, but you're very 
> > clearly
> > exceeding that.
> > 
> > Greetings,
> > 
> > Andres Freund
> I’m so sorry for that. I think I’m not very familiar with pg, so I ask many 
> naive questions. And I apologize for my behavior.

I think you might find our IRC channel a more natural fit for getting
your questions answered:

https://www.postgresql.org/community/irc/

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Only you can decide what is important to you.




Re: Set enable_seqscan doesn't take effect?

2023-09-28 Thread jacktby jacktby


> 2023年9月28日 12:26,David G. Johnston  写道:
> 
> On Wednesday, September 27, 2023, jacktby jacktby  > wrote:
>> postgres=# SET enable_seqscan = off;
>> SET
>> postgres=# explain select * from t;
>>QUERY PLAN
>> -
>>  Seq Scan on t  (cost=100.00..123.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.
> 
Yes, I think that’s it.Thanks.

Re: Set enable_seqscan doesn't take effect?

2023-09-28 Thread jacktby jacktby


> 2023年9月28日 01:07,Andres Freund  写道:
> 
> Hi,
> 
> On 2023-09-28 00:37:41 +0800, jacktby jacktby wrote:
>> postgres=# SET enable_seqscan = off;
>> SET
>> postgres=# explain select * from t;
>>  QUERY PLAN
>> -
>> Seq Scan on t  (cost=100.00..123.60 rows=1360 width=32)
>> (1 row)
>> 
>> postgres=#  select * from t;
>>  a   
>> ---
>> [1,2]
>> (1 row)
> 
> Sorry to be the grump here:
> 
> You start several threads a week, often clearly not having done much, if any,
> prior research. Often even sending the same question to multiple lists. It
> should not be hard to find an explanation for the behaviour you see here.
> 
> pgsql-hackers isn't a "do my work for me service". We're hacking on
> postgres. It's fine to occasionally ask for direction, but you're very clearly
> exceeding that.
> 
> Greetings,
> 
> Andres Freund
I’m so sorry for that. I think I’m not very familiar with pg, so I ask many 
naive questions. And I apologize for my behavior.



Re: Set enable_seqscan doesn't take effect?

2023-09-27 Thread David G. Johnston
On Wednesday, September 27, 2023, jacktby jacktby  wrote:

> postgres=# SET enable_seqscan = off;
> SET
> postgres=# explain select * from t;
>QUERY PLAN
> -
>  Seq Scan on t  (cost=100.00..123.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.


Re: Set enable_seqscan doesn't take effect?

2023-09-27 Thread jacktby jacktby


> 2023年9月28日 01:07,Andres Freund  写道:
> 
> Hi,
> 
> On 2023-09-28 00:37:41 +0800, jacktby jacktby wrote:
>> postgres=# SET enable_seqscan = off;
>> SET
>> postgres=# explain select * from t;
>> QUERY PLAN
>> -
>> Seq Scan on t  (cost=100.00..123.60 rows=1360 width=32)
>> (1 row)
>> 
>> postgres=#  select * from t;
>> a   
>> ---
>> [1,2]
>> (1 row)
> 
> Sorry to be the grump here:
> 
> You start several threads a week, often clearly not having done much, if any,
> prior research. Often even sending the same question to multiple lists. It
> should not be hard to find an explanation for the behaviour you see here.
> 
> pgsql-hackers isn't a "do my work for me service". We're hacking on
> postgres. It's fine to occasionally ask for direction, but you're very clearly
> exceeding that.
> 
> Greetings,
> 
> Andres Freund
I’m so sorry for that. I think I’m not very familiar with pg, so I ask many 
naive questions. And I apologize for my behavior.



Re: Set enable_seqscan doesn't take effect?

2023-09-27 Thread jacktby jacktby


> 2023年9月28日 01:07,Andres Freund  写道:
> 
> Hi,
> 
> On 2023-09-28 00:37:41 +0800, jacktby jacktby wrote:
>> postgres=# SET enable_seqscan = off;
>> SET
>> postgres=# explain select * from t;
>>  QUERY PLAN
>> -
>> Seq Scan on t  (cost=100.00..123.60 rows=1360 width=32)
>> (1 row)
>> 
>> postgres=#  select * from t;
>>  a   
>> ---
>> [1,2]
>> (1 row)
> 
> Sorry to be the grump here:
> 
> You start several threads a week, often clearly not having done much, if any,
> prior research. Often even sending the same question to multiple lists. It
> should not be hard to find an explanation for the behaviour you see here.
> 
> pgsql-hackers isn't a "do my work for me service". We're hacking on
> postgres. It's fine to occasionally ask for direction, but you're very clearly
> exceeding that.
> 
> Greetings,
> 
> Andres Freund
I’m so sorry for that. I think I’m not very familiar with pg, so I ask many 
naive questions. And I apologize for my behavior.



Re: Set enable_seqscan doesn't take effect?

2023-09-27 Thread David Rowley
On Thu, 28 Sept 2023 at 13:47, jacktby jacktby  wrote:
>
> postgres=# SET enable_seqscan = off;
> SET
> postgres=# explain select * from t;
>QUERY PLAN
> -
>  Seq Scan on t  (cost=100.00..123.60 rows=1360 width=32)
> (1 row)
>
> postgres=#  select * from t;
>a
> ---
>  [1,2]
> (1 row)>

It may be worth checking what the manual says about this. I guess if
you assume the meaning from the GUC name, then it might be surprising.
If you're still surprised after reading the manual then please report
back.

David




Re: Set enable_seqscan doesn't take effect?

2023-09-27 Thread Andres Freund
Hi,

On 2023-09-28 00:37:41 +0800, jacktby jacktby wrote:
> postgres=# SET enable_seqscan = off;
> SET
> postgres=# explain select * from t;
>QUERY PLAN
> -
>  Seq Scan on t  (cost=100.00..123.60 rows=1360 width=32)
> (1 row)
> 
> postgres=#  select * from t;
>a   
> ---
>  [1,2]
> (1 row)

Sorry to be the grump here:

You start several threads a week, often clearly not having done much, if any,
prior research. Often even sending the same question to multiple lists. It
should not be hard to find an explanation for the behaviour you see here.

pgsql-hackers isn't a "do my work for me service". We're hacking on
postgres. It's fine to occasionally ask for direction, but you're very clearly
exceeding that.

Greetings,

Andres Freund




Set enable_seqscan doesn't take effect?

2023-09-27 Thread jacktby jacktby
postgres=# SET enable_seqscan = off;
SET
postgres=# explain select * from t;
   QUERY PLAN
-
 Seq Scan on t  (cost=100.00..123.60 rows=1360 width=32)
(1 row)

postgres=#  select * from t;
   a   
---
 [1,2]
(1 row)