Merlin, I tried the hack you suggested but that didn't work. Planner used
the same path.
The same query works much faster when using the raw SQL instead of DB view:
Here is the definition of DB View ‘job’
SELECT w.id,
w.parent_id,
w.status AS state,
w.percent_complete AS progre
We noticed that the following SQL query runs 3 times slower on the latest
version of PostgreSQL with parallel query execution. It would be helpful if
someone could shed light on why this is happening.
Here’s the time taken to execute them on older (v9.5.16) and newer versions
(v11.2) of PostgreSQL
Am 29.03.19 um 15:29 schrieb Stephan Schmidt:
PostgreSQL version: 11.2
Operating system: Linux
Description:
We have a wuite complex CTE which collects data fast enough for us and
has a ok execution plan.
When we insert the result into a table like
With _/some/_data AS (
SELECT….
), _
On Thu, Mar 28, 2019 at 5:44 PM Raj Gandhi wrote:
>
> + pgsql-performance
>
> On Thu, Mar 28, 2019 at 6:41 PM Raj Gandhi wrote:
>>
>> Hi everyone,
>>
>>
>>
>> I’m using LIMIT offset with DB view. Looks like query planner is applying
>> the LIMIT for DB view at the end after processing all rows.
PostgreSQL version: 11.2
Operating system: Linux
Description:
We have a wuite complex CTE which collects data fast enough for us and has a ok
execution plan.
When we insert the result into a table like
With _some_data AS (
SELECT….
), _some_other_data AS (
SELECT ….
)
INSERT INTO table1
