From: | Jan Kohnert <nospam001-lists(at)jan-kohnert(dot)de> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Implementing product-aggregate |
Date: | 2024-03-14 18:26:57 |
Message-ID: | 2646220.k3LOHGUjKi@kohni-mobil |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 documentation to little purpose. Using one makes your code
> not so portable to non-Postgres DBMSes, but you already crossed that
> bridge by deciding to use a custom aggregate.
thank you for clearifying this. We're not too concerned about portability. Let's face
the facts: Porting a reasonably complex database and the application using it
from one DBMS to another will almost certainly introduce an awful lot of
portability issues (f.e. the pseudo-types (big)serial, upserts, differences in merge
implementations, progammability, and so on). My main concern was, that
undocumented features sometimes tend to change without notice, since users
are not expected to use them..
> A bigger question is whether this implementation actually has the
> properties you want --- notably, maybe you should be using type
> float8 not numeric. Numeric would get pretty slow and be carrying
> an awful lot of decimal places by the end of the query, I fear.
This needs to be checked on our side. I was expecting, that using an aggregate
this way would be significantly faster than using exp(sum(log())). Though we're
not multiplying too many lines in a statement, if using the aggregate slows down
performance, we should propably stick the old way doing it.
Best regards!
--
MfG Jan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter J. Holzer | 2024-03-14 18:35:10 | Re: Postgresql docker health check |
Previous Message | David G. Johnston | 2024-03-14 18:12:38 | Re: select results on pg_class incomplete |