Seq Scan cost shown to be (cost=10000000000.00..10000000001.10)
Hello,
I set enable_seqscan=off and also accidentally dropped the only index
on a table (actually, drop extension pg_bigm cascade) and observe
following:
postgres=# explain select * from testdata where name like '%gi%';
QUERY PLAN
-----------------------------------------------------------------------------
Seq Scan on testdata (cost=10000000000.00..10000000001.10 rows=2 width=71)
Filter: (name ~~ '%gi%'::text)
(2 rows)
Although, I suspect the (dropped index + enable_seqscan) causes this,
is the cost shown in explain output some kind of default max or
something like that for such abnormal cases?
--
Amit Langote
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Mon, May 27, 2013 at 12:42 AM, Amit Langote <amitlangote09@gmail.com> wrote:
I set enable_seqscan=off and also accidentally dropped the only index
[...]
Seq Scan on testdata (cost=10000000000.00..10000000001.10 rows=2 width=71)
[...]
Although, I suspect the (dropped index + enable_seqscan) causes this,
is the cost shown in explain output some kind of default max or
something like that for such abnormal cases?
When you set enable_xxx=off, it not actually disables the xxx
operation, it sets the start cost to the high value (10000000000).
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
Profile: http://www.linkedin.com/in/grayhemp
Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979
Skype: gray-hemp
Jabber: gray.ru@gmail.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2013/5/27 Amit Langote <amitlangote09@gmail.com>
Although, I suspect the (dropped index + enable_seqscan) causes this,
is the cost shown in explain output some kind of default max or
something like that for such abnormal cases?
When one uses “enable_” settings to adjust planner behavior, PostgreSQL
just sets really high costs for the operations affected (like the one you
see).
As SeqScan is the only possible way to execute your query, it is still
choosen.
Somewhat related thread:
/messages/by-id/4D5B06AC.2020700@lelarge.info
--
Victor Y. Yegorov
Although, I suspect the (dropped index + enable_seqscan) causes this,
is the cost shown in explain output some kind of default max or
something like that for such abnormal cases?When you set enable_xxx=off, it not actually disables the xxx
operation, it sets the start cost to the high value (10000000000).
Oh, okay, thanks!
--
Amit Langote
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
When one uses “enable_” settings to adjust planner behavior, PostgreSQL
just sets really high costs for the operations affected (like the one you
see).As SeqScan is the only possible way to execute your query, it is still
choosen.
I get it. Thanks!
--
Amit Langote
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general