> Hi,
> I want to know what are the best practice to use in order to
> decompose a big query which contains so many joins.Is it recommended
> to use stored procedures ? or is there any other solution?
The main problem with SP's is that they can really screw up
optimization. Most of the time you'l
On Fri, 6 Apr 2018, pinker wrote:
Edson Carlos Ericksson Richter wrote
I don't know if there are best practices (each scenario requires its own
solution), but for plain complex SELECT queries, I do use "WITH"
queries... They work really well.
Be cautious with CTE's. They weren't meant to be a
On Fri, Apr 6, 2018 at 9:35 AM, pinker wrote:
> Edson Carlos Ericksson Richter wrote
> > I don't know if there are best practices (each scenario requires its own
> > solution), but for plain complex SELECT queries, I do use "WITH"
> > queries... They work really well.
>
> Be cautious with CTE's.
Edson Carlos Ericksson Richter wrote
> I don't know if there are best practices (each scenario requires its own
> solution), but for plain complex SELECT queries, I do use "WITH"
> queries... They work really well.
Be cautious with CTE's. They weren't meant to be an alternative to
subqueries and
Em 05/04/2018 19:39, hmidi slim escreveu:
Hi,
I want to know what are the best practice to use in order to decompose
a big query which contains so many joins.Is it recommended to use
stored procedures ? or is there any other solution?
I don't know if there are best practices (each scenario
On Thu, Apr 5, 2018 at 3:39 PM, hmidi slim wrote:
> I want to know what are the best practice to use in order to decompose a
> big query which contains so many joins.Is it recommended to use stored
> procedures ? or is there any other solution?
>
Views are another solution.
https://www.postgres
Hi,
I want to know what are the best practice to use in order to decompose a
big query which contains so many joins.Is it recommended to use stored
procedures ? or is there any other solution?
