Hi Raj,
I have long time without working on pgsql performance, but you can try
materialized views or if you are already using its try apply some
performance tips...
This are some link i found in a fast search, but if you solution is going
by this way this can be a kickstart to solve your problem.
Thanks,
Sameer
+65 81100350
*Please consider the environment before printing this e-mail!*
On Mon, Apr 1, 2019 at 9:57 PM Raj Gandhi wrote:
> Any other idea how to resolve the performance issue with the database view?
>
> On Fri, Mar 29, 2019 at 7:38 PM Raj Gandhi wrote:
>
>> Merlin, I tried
Thanks Rui. The performance of using function is close to the plain SQL.
Why Query planner is choosing different path with DB view?
explain analyze select foo(101,0);
QUERY
PLAN
---
Any other idea how to resolve the performance issue with the database view?
On Fri, Mar 29, 2019 at 7:38 PM Raj Gandhi wrote:
> 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
>
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
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.
+ 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.
>
> When running same SQL that was used to create the DB view, LIMI
