Re: stored procedure slower when called through c client than pgadmin

2013/3/8 Bradley Russell <bradley(dot)russell(at)npcinternational(dot)com>:
> I will see if I can strip the code down more to a smaller sample. It is part of a larger project. Though I have debugged it to confirm on that connection the only command being sent is the select of the stored procedure.
>
> The strange thing is the time is actually spent running on the server. We can see the query running in server status on the server for the entire hour.
>
> We have also tried it in different orders so we don't believe it is a caching effect.

please, check if you use same database from both environments.

Usually, source of this kind of strange issues are hidden different
environments.

Next possibility is different configuration related to different users
??? Maybe ...

Pavel

>
> Thanks,
> Bradley Russell
> Programmer
> NPC International
>
> -----Original Message-----
> From: Pavel Stehule [mailto:pavel(dot)stehule(at)gmail(dot)com]
> Sent: Friday, March 08, 2013 10:56 AM
> To: Bradley Russell
> Cc: PostgreSQL General (pgsql-general(at)postgresql(dot)org)
> Subject: Re: [GENERAL] stored procedure slower when called through c client than pgadmin
>
> Hello
>
> 2013/3/8 Bradley Russell <bradley(dot)russell(at)npcinternational(dot)com>:
>> We have a stored procedure that takes two integers as parameters, a start
>> date and a stop date.
>>
>>
>>
>> It runs some calculations on a table and updates some columns in the same
>> table.
>>
>>
>>
>> The table being updated is partitioned.
>>
>>
>>
>> The server version is 9.1.8.
>>
>>
>>
>> When we run this stored procedure through pgadmin it runs in around 10 – 15
>> minutes.
>>
>>
>>
>> When we run the same stored procedure through our c++ program that is using
>> libpq it takes 1 hour.
>>
>>
>>
>> Anyone have some insight on what could be the difference?
>>
>
> It is really strange - I never seen this issue. Can you send a test
> example or can you send source code?
>
> Regards
>
> Pavel Stehule
>
>>
>>
>> Thanks,
>> Brad
>