On Fri, Apr 7, 2017 at 12:54 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 04/07/2017 06:31 PM, Merlin Moncure wrote:
>>> I think your math is off. Looking at your attachments, planning time
>>> is 0.056ms, not 0.56ms. This is in no way relevant to performance on
>>> the order of your measur
Tomas Vondra writes:
> On 04/07/2017 06:31 PM, Merlin Moncure wrote:
>> I think your math is off. Looking at your attachments, planning time
>> is 0.056ms, not 0.56ms. This is in no way relevant to performance on
>> the order of your measured TPS. How are you measuring TPS?
> Not sure where d
On 04/07/2017 06:31 PM, Merlin Moncure wrote:
On Fri, Apr 7, 2017 at 5:16 AM, Prakash Itnal wrote:
Hello,
We currently use psotgres 9.3 in our products. Recently we upgraded to
postgres 9.6. But with 9.6 we have seen a drastic reduction in throughput.
After analyzing carefully I found that "pl
On Fri, Apr 7, 2017 at 5:16 AM, Prakash Itnal wrote:
> Hello,
>
> We currently use psotgres 9.3 in our products. Recently we upgraded to
> postgres 9.6. But with 9.6 we have seen a drastic reduction in throughput.
> After analyzing carefully I found that "planner time" in 9.6 is very high.
> Below
Hello,
We currently use psotgres 9.3 in our products. Recently we upgraded to
postgres 9.6. But with 9.6 we have seen a drastic reduction in throughput.
After analyzing carefully I found that "planner time" in 9.6 is very high.
Below are the details:
Scenario:
1 Create a table with 10 rows.
2