On Tue, Sep 23, 2008 at 11:53 PM, chetan N <[EMAIL PROTECTED]> wrote:
> Hey does anybody know how to call stored procedure written in pgsql using
> hibernate concecpt with java application... I wanted to know how mapping
> takes place. Please could anybody help me out
This is the wrong mailing
Hey does anybody know how to call stored procedure written in pgsql using
hibernate concecpt with java application... I wanted to know how mapping
takes place. Please could anybody help me out
Hello,
I am returning back to my patch from last previous year
http://archives.postgresql.org/pgsql-patches/2008-04/msg00166.php .
The main objection was about integration encryption method into core.
There was others proposal - using an obfuscate languages. I dislike
it. It lot of duplicate code
This has been saved for the next commit-fest:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Martin Pihlak wrote:
> Howdy,
>
> Here's an updated version of the function stats patch. The biggest change is
Howdy,
> Did you post an updated patch to HEAD?
>
No, but I guess its just about time. Hopefully I'll have
something to show next week.
regards,
Martin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
Hi,
> Good. I'll bring the patch up to date with HEAD.
Did you post an updated patch to HEAD?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Hello
On 03/12/2007, Dragan Zubac <[EMAIL PROTECTED]> wrote:
> Hello
>
> What I have noticed is that when I don't use procedure
> at all,there's only 2-5 locks in pg_locks,after I
> start application which uses stored procedure the
> number in pg_locks increase rapidly to steady 75 even
> to 130 a
Hello
What I have noticed is that when I don't use procedure
at all,there's only 2-5 locks in pg_locks,after I
start application which uses stored procedure the
number in pg_locks increase rapidly to steady 75 even
to 130 at certain moments.
Any clue why procedure usage might increase locks so
he
Hello
Here's the stored procedure itself,as well as the
related tables involved in it's calculations.
The idea for procedure is to find longest prefix match
for destination number,try to find it in table
'billing' for particular users,find the price,and
insert message into history and inqueue tabl
Hello
Please find in attachment stored procedure
(proc_uni.txt),as well as description of tables
involved in calculations.
The idea for procedure is to find longest prefix match
for destination number,try to find it in table
'billing' for particular users,find the price,and
insert message into his
On Dec 2, 2007 7:40 AM, Dragan Zubac <[EMAIL PROTECTED]> wrote:
> Hello
>
> I have a stored procedure which does the billing stuff
> in our system,it works ok,but if I put in
> production,where there is some 5-10 billing events per
> second,the whole database slows down. It won't even
> drop some
Hello
I have a stored procedure which does the billing stuff
in our system,it works ok,but if I put in
production,where there is some 5-10 billing events per
second,the whole database slows down. It won't even
drop some test table,reindex,vacuum,things which were
done before in the blink of an eye
hubert depesz lubaczewski wrote:
On Thu, Sep 20, 2007 at 05:34:32PM -0700, Neil Conway wrote:
That seems a confusing set of values. Perhaps "off", "pl", and "all"
would be clearer?
I'm curious if you've measured the performance overhead of enabling this
functionality.
i'm quite worried about "
On Thu, Sep 20, 2007 at 05:34:32PM -0700, Neil Conway wrote:
> That seems a confusing set of values. Perhaps "off", "pl", and "all"
> would be clearer?
> I'm curious if you've measured the performance overhead of enabling this
> functionality.
i'm quite worried about "all" setting.
all operators a
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Martin Pihlak wrote:
> Howdy,
>
> Here's an updated version of the function stats patch. The biggest change is
> tha
It seems that the overhead is unnoticeable if disabled, very visible
for lightweight functions and heavy callers. Almost unnoticeable for
more compute intensive functions.
The very high system times seem odd. Maybe you have a machine with
slow gettimeofday()?
So it seems (on Ubuntu 7.04). Re
Martin Pihlak <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> That seems a confusing set of values. Perhaps "off", "pl", and "all"
>> would be clearer?
> Makes sense. It appears that the stats_ prefixed GUC names are deprecated now.
> Will rename to "track_functions" and change values to "off"
Neil Conway wrote:
On Thu, 2007-09-20 at 16:08 +0300, Martin Pihlak wrote:
The GUC variable stats_function_level now takes 3 values: on, off and all.
That seems a confusing set of values. Perhaps "off", "pl", and "all"
would be clearer?
Makes sense. It appears that the stats_ prefixed GUC na
On Thu, 2007-09-20 at 16:08 +0300, Martin Pihlak wrote:
> The GUC variable stats_function_level now takes 3 values: on, off and all.
That seems a confusing set of values. Perhaps "off", "pl", and "all"
would be clearer?
I'm curious if you've measured the performance overhead of enabling this
func
Howdy,
Here's an updated version of the function stats patch. The biggest change is
that by default only procedural language functions are counted. The GUC variable
stats_function_level now takes 3 values: on, off and all. The latter also
counts SQL and C language functions, "on" means only to co
Tom Lane wrote:
I really dislike that approach to deciding which functions to count.
The main problem with it is that it will try to count C-language
functions that are added after initdb, such as contrib stuff and
third-party add-ons like postgis. The percentage overhead for a
typical short C f
Neil Conway wrote:
(schemaname, procname, nargs) is still ambiguous in the face of function
overloading. Although the presence of procid uniquely identifies each
function anyway, if you're going to include the name and argument
information, it might be worth including the argument types as well
Martin Pihlak <[EMAIL PROTECTED]> writes:
> I'm working on a patch to extend the stats collector to handle stored
> procedure
> statistics (call counts, duration etc).
> ...
> Only functions with oid >= FirstNormalObjectId are accounted.
I really dislike that approach to deciding which functions
On Fri, 2007-07-13 at 14:11 +0300, Martin Pihlak wrote:
> I'm working on a patch to extend the stats collector to handle stored
> procedure
> statistics (call counts, duration etc). The goal is to make this information
> visible via pg_stat functions/views. The collection would be controllable via
Howdy,
I'm working on a patch to extend the stats collector to handle stored procedure
statistics (call counts, duration etc). The goal is to make this information
visible via pg_stat functions/views. The collection would be controllable via
"stats_function_level" GUC and will have minimal overhe
25 matches
Mail list logo
