ns if possible)?
Is there a better solution?
Thank you,
*David Grelaud*
inserts, updates and deletes every day as you.
Hopefully, we've never experienced a data corruption until now ("crossed
fingers").
*David Grelaud*
2016-02-10 8:06 GMT+01:00 Josh berkus :
> On 02/10/2016 05:10 AM, ioan ghip wrote:
>
>> I have a Firebird SQL database r
to complete. The performance difference is huge.
I mean, even if the plan is not the best one 100% of the time, it should at
least choose a "risk-free" plan, without these "bad" nested-loops. It is
maybe easier said than done but we want to try.
Regards,
*David Grelaud*
20
loop).
We thought at the beginning we were alone but it seems to be a problem of
most database systems.
What do you think about the paragraph 4.1 of this paper
http://www.vldb.org/pvldb/vol9/p204-leis.pdf ?
Regards,
-------
David Grelaud,
Ideolys.
2016-01-13 16:02 GMT+01:00 Tom Lane :
d like to find a "simple" long-term solution to this
under-estimation cost problem, which generate hazarduous performance
regressions in our production environments.
We would like to hear critiques or other solutions from PostgreSQL experts.
We would like to help developing and testing the solution.
Thank you very much!
Regards,
---
David Grelaud,
Ideolys.
