Re: Question on postgres certified OS platforms
On Thu, 2020-10-15 at 17:22 +, Raj Iyer wrote: > Is there information available on what versions of Postgres are certified and > supported on what Operating System platforms. There is no certification; you are stuck in closed source land. Here is a list of operating systems that are supported: https://www.postgresql.org/docs/current/supported-platforms.html Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
Re: Date Format 9999-12-31-00.00.00.000000
On Thu, 2020-10-15 at 20:58 +, Dirk Krautschick wrote:
> because of a migration from DB2 we have a lot of timestamps like
>
> -12-31-00.00.00.00
>
> What would be the best way to handle this in Postgres also related
> to overhead and performance (index usage?).
>
> Or is
>
> TO_TIMESTAMP('-12-31-00.00.00.00', '-MM-DD-HH24.MI.SS.US')
>
> the only way? And isn't it possible to define this like NLS parameters in
> Oracle
> system wide?
I would replace them with 'infinity', which is a valid timestamp value
in PostgreSQL.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
RE: Does the work made by vaccum in the current pass is lost when interrupted?
Thank you Michael for your suggestion, I will reduce vacuum_cost_delay and increasing vacuum_cost_limit to speedup vacuum. But the I/O system is very solicitated on PROD system and I do not want to impact end user performance. If aggressive cost_delay and vacuum_cost_limit slow down significatively end user performance, I may have to kill the vacuum, but would like to keep as much vacuum work as possible. My concern is about the size of the max_dead_tuples buffer determined by the autovacuum_work_mem * autovacuum_work_mem is currently 1GB (default to maintenance_work_mem) When I ran a vacuum on a DEV system and it made a single “scanning heap/vacuuming indexes/vacuuming heap” cycle of about 12 hours. The vacuuming indexes phase is half the total time (6 hrs). Q1: I guess that if I have to kill the vacuum midway, I will lose all the work it did during the scanning heap step? Right? Q2: If I reduce autovacuum_work_mem to 32MB, is there any side effect performance on the vacuum? thanks
Re: UUID with variable length
Greetings, * Christophe Pettus (x...@thebuild.com) wrote: > > On Oct 15, 2020, at 13:49, Dirk Krautschick > > wrote: > > Or do you have some other ideas how to use a primary key datatype like UUID > > but with variable length? > > You're probably best off storing it as a VARCHAR() with a check constraint or > constraint trigger that validates it. Surely a bytea would be better and be less overhead than storing it as text.. Thanks, Stephen signature.asc Description: PGP signature
Re: UUID with variable length
On 2020-Oct-15, Dirk Krautschick wrote: > Hi, > > I have here a situation with the usage of UUID. Here the database user > allows UUIDs with less then 16 byte lengths (please don't ask :-) ). > > Of course there are some technical ways to do the filling of the not > used bytes but I hope there is a better solution. This UUID is used as > primary Key and for indexing. How much shorter than 16 bytes are you expecting your UUIDs to be? If they're not short enough, you'll still have to store a lot of padding space, and considering that you'll need a length indicator if you use variable length, it does not really sound like you'll save much actual space. And you'll definitely be getting a slower datatype, since doing operations will become more complex. If this were me, I would see about zeroing out the unused bytes and not waste a lot of developer time on this.
