Le 11/10/2017 à 16:11, Purav Chovatia a écrit :
Thanks.
We looked at pg_stat_statements and we see execution count & total
time taken. But that still does not help me to identify why is it slow
or what is taking time or where is the wait.
btw, does pg_stat_statements add considerable overhe
2017-10-11 18:52 GMT+02:00 Purav Chovatia :
> Yes, there is some code to catch exceptions like unique constraint
> violation and no data found. Do you suggest we trying by commenting that
> part? btw, the dataset is a controlled one, so what I can confirm is we are
> not hitting any exceptions.
>
> Yes, there is some code to catch exceptions like unique constraint violation
> and no data found. Do you suggest we trying by commenting that part?
That is likely it. Comment that out and test.
If you still need to handle a unique violation, see if you can instead
use the ON CONFLICT clause on
Yes, there is some code to catch exceptions like unique constraint
violation and no data found. Do you suggest we trying by commenting that
part? btw, the dataset is a controlled one, so what I can confirm is we are
not hitting any exceptions.
Thanks
On 11 October 2017 at 22:07, Adam Brusselback
Is there any error handling in there? I remember seeing performance
issues if you put in any code to catch exceptions.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Thanks Pavel. Our SPs are not doing any mathematical calculations. Its
mostly if-else, so I would expect good performance.
On 11 October 2017 at 19:50, Pavel Stehule wrote:
>
>
> 2017-10-11 15:59 GMT+02:00 Purav Chovatia :
>
>> Thanks Laurenz, am having a look at perf.
>>
>> Can you pls help und
2017-10-11 15:59 GMT+02:00 Purav Chovatia :
> Thanks Laurenz, am having a look at perf.
>
> Can you pls help understand what exactly do you mean when you say "PL/pgSQL
> is not optimized for performance like PL/SQL". Do you mean to indicate that
> app firing queries/DMLs directly would be a better
Thanks.
We looked at pg_stat_statements and we see execution count & total time
taken. But that still does not help me to identify why is it slow or what
is taking time or where is the wait.
btw, does pg_stat_statements add considerable overhead? Coming from the
Oracle world, we are very used to
Thanks Laurenz, am having a look at perf.
Can you pls help understand what exactly do you mean when you say "PL/pgSQL
is not optimized for performance like PL/SQL". Do you mean to indicate that
app firing queries/DMLs directly would be a better option as compared to
putting those in Stored Procs?
2017-10-03 17:17 GMT+02:00 Adam Brusselback :
> There is also the option of pg_stat_statements: https://
> www.postgresql.org/docs/current/static/pgstatstatements.html and
> auto_explain: https://www.postgresql.org/docs/current/
> static/auto-explain.html
>
> These should help you identify what is
There is also the option of pg_stat_statements:
https://www.postgresql.org/docs/current/static/pgstatstatements.html and
auto_explain:
https://www.postgresql.org/docs/current/static/auto-explain.html
These should help you identify what is slowing things down. There is no
reason I could think of y
Purav Chovatia wrote:
> I come from Oracle world and we are porting all our applications to
> postgresql.
>
> The application calls 2 stored procs,
> - first one does a few selects and then an insert
> - second one does an update
>
> The main table on which the insert and the update happens is
Hello,
I come from Oracle world and we are porting all our applications to
postgresql.
The application calls 2 stored procs,
- first one does a few selects and then an insert
- second one does an update
The main table on which the insert and the update happens is truncated
before every performan
On 4/11/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Merlin Moncure wrote:
> > pl/pgsql procedures are a very thin layer over the query engine.
> > Generally, they run about the same speed as SQL but you are not making
> > apples to apples comparison. One of the few but annoying limitations
> >
Merlin Moncure wrote:
> On 4/11/06, Simon Dale <[EMAIL PROTECTED]> wrote:
> > I'm trying to evaluate PostgreSQL as a database that will have to store a
> > high volume of data and access that data frequently. One of the features on
> > our wish list is to be able to use stored procedures to access
commit work (!)
Regards
Henk Sanders
> -Oorspronkelijk bericht-
> Van: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Merlin Moncure
> Verzonden: dinsdag 11 april 2006 15:50
> Aan: Simon Dale
> CC: pgsql-performance@postgresql.org
> Onderwerp: Re: [PERF
[EMAIL PROTECTED] ("Simon Dale") wrote:
> Event with the planning removed, the function still
> performs
> significantly slower than the raw SQL. Is that normal or am I doing something
> wrong
> with the creation or calling of the
> function?
I'd expect this, yes.
You're doing something via "st
On 4/11/06, Simon Dale <[EMAIL PROTECTED]> wrote:
> I'm trying to evaluate PostgreSQL as a database that will have to store a
> high volume of data and access that data frequently. One of the features on
> our wish list is to be able to use stored procedures to access the data and
> I was wondering
Rajesh Kumar Mallah wrote:
On 4/11/06, Simon Dale <[EMAIL PROTECTED]> wrote:
I'm trying to evaluate PostgreSQL as a database that will have to store a
high volume of data and access that data frequently. One of the features on
our wish list is to be able to use stored procedures to access the d
On 4/11/06, Simon Dale <[EMAIL PROTECTED]> wrote:
>
>
>
> Hi,
>
>
>
> I'm trying to evaluate PostgreSQL as a database that will have to store a
> high volume of data and access that data frequently. One of the features on
> our wish list is to be able to use stored procedures to access the data and
On 4/11/06, Simon Dale <[EMAIL PROTECTED]> wrote:
I'm trying to evaluate PostgreSQL as a database that
will have to store a high volume of data and access that data frequently. One
of the features on our wish list is to be able to use stored procedures to
access the data and I was wond
Hi,
I’m trying to evaluate PostgreSQL as a database that
will have to store a high volume of data and access that data frequently. One
of the features on our wish list is to be able to use stored procedures to
access the data and I was wondering if it is usual for stored procedures to
p
22 matches
Mail list logo
