On Tue, Apr 07, 2020 at 05:20:47PM +0530, daya airody wrote:
> we are looking for a PostgreSQL DBA to help us in tuning our database.
You can start here:
https://www.postgresql.org/support/professional_support/
--
Justin
hi folks,
we are looking for a PostgreSQL DBA to help us in tuning our database.
Could you please recommend somebody in your network?
thanks,
--daya--
That plan looks like it might have been cropped in places, and the
formatting is making it tricky to help.
Could you try again, pasting the plan into https://explain.depesz.com/ to
make it easier to review?
On Fri, Apr 3, 2020 at 5:18 PM dangal wrote:
> Justin thank you very much for your answe
> RV>> It simply is the way the application stores the data. For Oracle
> we are storing in XML and JSON format, for postgres, due do
> limitations of XML api, we are storing in VARCHAR.
Why not use JSON in Postgres then?
Postgres' JSON functions are at least as powerful as Oracle's (if not bette
Rick Vincent schrieb am 07.04.2020 um 11:08:
> The function is defined as below, so no use of VOLATILE.
If you don't specify anything, the default is VOLATILE.
So your function *is* volatile.
> CREATE OR REPLACE FUNCTION extractValueJS (sVar text, nfm INTEGER, nvm
> INTEGER)
> RETURNS VARCHAR
Hi Tom,
The function is defined as below, so no use of VOLATILE. Let me know if you
need any other information. I am hoping the below will further clarify the
issue.
CREATE OR REPLACE FUNCTION extractValueJS (sVar text, nfm INTEGER, nvm INTEGER)
RETURNS VARCHAR as $$
declare
sRet text := '';
Hi Justin,
You said, " Is there a reason why you don't store the extracted value in its
own column ?"
RV>> It simply is the way the application stores the data. For Oracle we are
storing in XML and JSON format, for postgres, due do limitations of XML api, we
are storing in VARCHAR. We can't
