Re: Sudden FTS-related error from parallel worker in 9.6

On Tue, Oct 4, 2016 at 8:37 AM, Devrim Gündüz <devrim(at)gunduz(dot)org> wrote:
>
>
> I am not 100% familiar with this, but IIRC you need to create this in that
> database, too.
>

No I don't. I'm not using FTS in that database.
I undertand that setting this FTS option cluster-wide might be not a good
solution, but nobody prohibits doing so.

>
> I first created the tables as you did, and then:
>
> postgres=# SELECT version();
> version
> ------------------------------------------------------------
> ---------------------------------------------
> PostgreSQL 9.6.0 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 6.2.1
> 20160916 (Red Hat 6.2.1-2), 64-bit
> (1 row)
>
> postgres=# CREATE TEXT SEARCH CONFIGURATION ru (COPY=russian);
> CREATE TEXT SEARCH CONFIGURATION
> postgres=# EXPLAIN ANALYZE SELECT min(ts) FROM test;
> QUERY PLAN
> ------------------------------------------------------------
> -----------------------------------------------------
> Aggregate (cost=2266.00..2266.01 rows=1 width=8) (actual
> time=15.740..15.740 rows=1 loops=1)
> -> Seq Scan on test (cost=0.00..2016.00 rows=100000 width=8) (actual
> time=0.006..8.032 rows=100000 loops=1)
> Planning time: 0.212 ms
> Execution time: 15.782 ms
> (4 rows)
>
> postgres=# SET default_text_search_config TO ru;
> SET
> postgres=# EXPLAIN ANALYZE SELECT min(ts) FROM test;
> QUERY PLAN
> ------------------------------------------------------------
> -----------------------------------------------------
> Aggregate (cost=2266.00..2266.01 rows=1 width=8) (actual
> time=13.292..13.293 rows=1 loops=1)
> -> Seq Scan on test (cost=0.00..2016.00 rows=100000 width=8) (actual
> time=0.009..6.572 rows=100000 loops=1)
> Planning time: 0.069 ms
> Execution time: 13.317 ms
> (4 rows)

> postgres=# SET max_parallel_workers_per_gather TO 8;
> SET
> postgres=# EXPLAIN ANALYZE SELECT min(ts) FROM test;
> QUERY PLAN
> ------------------------------------------------------------
> -----------------------------------------------------
> Aggregate (cost=2266.00..2266.01 rows=1 width=8) (actual
> time=13.701..13.701 rows=1 loops=1)
> -> Seq Scan on test (cost=0.00..2016.00 rows=100000 width=8) (actual
> time=0.009..6.882 rows=100000 loops=1)
> Planning time: 0.063 ms
> Execution time: 13.722 ms
> (4 rows)
>

In your case parallel execution didn't happen. Try
setting force_parallel_mode to on, for testing purposes.
Also, to repeat my case, you need to try running this query in 'test'
database, where 'ru' configuration doesn't exist.

>
> postgres=# \c test
> You are now connected to database "test" as user "postgres".
> test=# SET default_text_search_config TO ru;
> ERROR: invalid value for parameter "default_text_search_config": "ru"
>

It's ok and runs like expected. But it by no means relates to my case,
where the query wasn't meant to be touching FTS stuff.