Hi again,
Am Montag, 11. März 2024, 10:16:33 CET schrieb Jan Kohnert:
> create aggregate prod(numeric) (sfunc = numeric_mul, stype = numeric)
my basic idea was creating a function
create function multiply(arg1 numeric, arg2 numeric)
returns numeric
language sql
immutable
returns
Jan Kohnert writes:
> Am Montag, 11. März 2024, 10:16:33 CET schrieb Jan Kohnert:
>> create aggregate prod(numeric) (sfunc = numeric_mul, stype = numeric)
> ...
> Then again, this seems odd, too, since we're only reimplementing basic stuff
> that's
> already there.
I wouldn't be concerned about
Hi
I am trying to access PostgreSQL meta data, possibly in a vane attempt
to get size data.
I use DbVis with a connection as shown in https://ibb.co/2SDzhXt . I try
to get information on a regular table "umsaetze". When doing the DbVis
object I can see them - https://ibb.co/WxMnY2c . If I ex
On 3/14/24 09:41, Thiemo Kellner wrote:
Hi
I am trying to access PostgreSQL meta data, possibly in a vane attempt
to get size data.
I use DbVis with a connection as shown in https://ibb.co/2SDzhXt . I try
to get information on a regular table "umsaetze". When doing the DbVis
object I can se
Thanks for the enlightenment. A pity. I suppose, there is no working
around this?
Am 14.03.2024 um 18:01 schrieb Adrian Klaver:
On 3/14/24 09:41, Thiemo Kellner wrote:
Hi
I am trying to access PostgreSQL meta data, possibly in a vane attempt
to get size data.
I use DbVis with a connection
On Thu, Mar 14, 2024, 11:08 Thiemo Kellner
wrote:
> Thanks for the enlightenment. A pity. I suppose, there is no working
> around this?
Write a script to do the query in a loop on all databases - that catalog is
global.
David J.
Hello,
Am Donnerstag, 14. März 2024, 15:17:58 CET schrieb Tom Lane:
> I wouldn't be concerned about relying on numeric_mul (or any of the
> other functions underlying standard operators). They're undocumented
> only because documenting both the functions and the operators would
> bloat the docume
On 2024-03-12 15:43:13 +0100, Amna Abdul Rehman wrote:
> When my application runs overnight, I receive the error message
> 'FATAL: Sorry, too many clients already.' To address this, I increased
> the number of max_connections to 3000, 5000, and also 1, but I
> still receive the error. Now, I'm
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) SELECT
products_inventory_delta.upc FROM products_inventory_delta
On Fri, 15 Mar 2024 at 07:13, David G. Johnston
wrote:
> On Thu, Mar 14, 2024, 11:08 Thiemo Kellner
> wrote:
>>
>> Thanks for the enlightenment. A pity. I suppose, there is no working
>> around this?
>
> Write a script to do the query in a loop on all databases - that catalog is
> global.
Yeah
On Fri, 15 Mar 2024 at 08:01, 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.
>Buffers: shared hit=33359 read=6590 dirtied=9379
> Executio
11 matches
Mail list logo