That's a very vague question, but you can trace exactly what is happening
by issuing
SET log_statement = 'all';
Ideally at the session level by your application, but can also set it at
the database and user level. If all else fails, set it globally (i.e.
postgresql.conf). Turn it off again as soo
Thanks Adrian,
I have been to the articles but it didn't help. Many of them have mentioned
this type of issues but not the solution.
And my main concern is if python library is able to perform fast operation
why ODBC is too much slow. And I have to use ODBC for my application which
is in power b
On 3/15/24 10:58 AM, vedant patel wrote:
Thanks Adrian,
I have been to the articles but it didn't help. Many of them have
mentioned this type of issues but not the solution.
That is why you should ask over on the ODBC list, that is where the
folks who develop and use the driver hang out.
On 3/14/24 11:04 PM, Bandi, Venkataramana - Dell Team wrote:
Hi Team,
We are using JPA entities to persists the records into Postgres SQL DB
and its working for all the nodes but one of the node data is not
persisting and it’s not giving any DB related errors/exception. We
just want to trac
On 3/15/24 3:40 AM, vedant patel wrote:
Hello There,
Recently, we've encountered some performance issues with the ODBC
driver provided by Postgres. Upon investigation, we noticed that
switching from the UNICODE to ANSI driver resulted in performance
improvements for some queries, albeit at t
Hello There,
Recently, we've encountered some performance issues with the ODBC driver
provided by Postgres. Upon investigation, we noticed that switching from
the UNICODE to ANSI driver resulted in performance improvements for some
queries, albeit at the expense of others.
To delve deeper into th
Hi Team,
We are using JPA entities to persists the records into Postgres SQL DB and its
working for all the nodes but one of the node data is not persisting and it's
not giving any DB related errors/exception. We just want to trace out this
scenario on transaction level whether transaction is c
On 3/15/24 03:42, Thiemo Kellner wrote:
You solve a problem that no one has. Data belonging together may still
be divided into schemas in a database. Thus, the metadata is also
reported and archived individually per database.
I am not sure, we are taking about the same problem, but would be
s
https://wiki.postgresql.org/wiki/Monitoring
Thanks for the URL. I am not too keen to re-invent the wheel. Although
it teaches me on PostgreSQL.
You could also create a PostgreSQL foreign server for each of the other
databases, which would let you issue a query to UNION together the results of a
query on all of the catalogs. This would require creating a foreign table for
pg_class in the other databases.
Thanks. So many possibilit
On Fri, Mar 15, 2024 at 6:43 AM Thiemo Kellner
wrote:
> I am not sure, we are taking about the same problem, but would be
> surprised to be the only one having experienced filling disks.
...
> So, if I have a disk getting filled up, I would like to get easily
> information on the problematic
>
On Fri, Mar 15, 2024 at 6:26 AM Rajesh S wrote:
> I wanted to implement a new "=" (equal) operator with LEFTARG as numeric
> and RIGHTARG as varchar. But after creating the function and operator,
> psql shows the error "operator is only a shell: character varying =
> numeric
>
Your operator has
> On Mar 15, 2024, at 03:30, Thiemo Kellner wrote:
> Thanks for the ideas. As I would want to keep it in the database, dblink
> would be the way to go. Maybe, I will create a prodedure that creates a view
> in the monitor schema accessing the respective databases with union all to
> concaten
You solve a problem that no one has. Data belonging together may still be
divided into schemas in a database. Thus, the metadata is also reported and
archived individually per database.
I am not sure, we are taking about the same problem, but would be
surprised to be the only one having exper
Am 14.03.2024 um 21:03 schrieb David Rowley:
Yeah, maybe dblink and a LATERAL join might be an easy way. Something like:
create extension dblink;
select d.datname,c.relname from pg_database d, lateral (select * from
dblink('dbname='||d.datname,$$select relname from pg_class where
relname = 'p
Hi,
I wanted to implement a new "=" (equal) operator with LEFTARG as numeric
and RIGHTARG as varchar. But after creating the function and operator,
psql shows the error "operator is only a shell: character varying =
numeric LINE 1: ...lect LIEN_AC_NO from deposit_lien where
deposit_no='00021
On Fri, 2024-03-15 at 00:31 +0530, hassan rafi wrote:
> We have migrated to postgres version 16.1, but still due to very high update
> activity on our DB, we are seeing elevated response times, though now the
> planning time is less.
>
> catalog-v2=> explain (analyze, verbose, settings, buffers) S
17 matches
Mail list logo
