Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t8NOJ-003npT-8a for pgsql-admin@arkaria.postgresql.org; Tue, 05 Nov 2024 17:30:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t8NOG-00GNZU-LK for pgsql-admin@arkaria.postgresql.org; Tue, 05 Nov 2024 17:30:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t8NOG-00GNZD-5s for pgsql-admin@lists.postgresql.org; Tue, 05 Nov 2024 17:30:52 +0000 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t8NOD-000L2B-Cq for pgsql-admin@postgresql.org; Tue, 05 Nov 2024 17:30:51 +0000 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2fb5014e2daso53069571fa.0 for ; Tue, 05 Nov 2024 09:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730827848; x=1731432648; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iNBxD1z+GtZ3knZoqAkJenF5AqAmHy7eVXY83OH1RVk=; b=XbPxBXNn60aSaGFi4QLiuAj750wRTg44AsOy+mJRaUNSWAxby7rUzPbMTFv5/fgewh xI+xidycrl3XSwV8oN855BPPCIf6gBb9vdScLwfJriaVHo/ZdDIg4pYVKy5dqqPPXwcq jNNVBZ3YyKwq6+sa1uqggqhkQBaDszjPIxbop/It7VlTJDzVk2oSXTS2mzoy5e3E62Wx WQtV0iTUJ3EFkDYbmvg8PlTGYy0Q4zHRnFZW9VMhvdnz7qFfo4m0h6/H7rXAaYVWccs8 oXxrqy1IQdWLgQbFPXIungrWI2GAkXqxYM9C5U23EDTKPhcFhFm2lq4lkRqG4s+V6tIq ahtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730827848; x=1731432648; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iNBxD1z+GtZ3knZoqAkJenF5AqAmHy7eVXY83OH1RVk=; b=FwZY/nAiO/k5ZPnta37osjpbPzgCId00x4y0/L9jF2ByEiVfm4uAfwUI9TNX22C3Gb 3+q4E+fcdph3TRzz2QM2zizxzJOvpUl/gWzgy1jVfTvmmpTN1ZJQOVfJo/cGcz+IZjk7 oKhzI9M0GRpIq5yFyXNcT3FECfLykv9PTowNak0Dtw2fkXQ3xuqixsuousaPk9WqQK/v OkSAOu5VtKd5mZnwZYIoAvdEhOWF2SyFrqX40rWOeBKauZ3oVP/Cl7sQM+1fbAez1la8 goHefeR1oZDDmb1j27u5huZ+uFgatob5e9ViYPWHxE2bP8PtFhQLPb21YdZtviltXGTE +dPA== X-Forwarded-Encrypted: i=1; AJvYcCW3kGHiffYAVh12SJTKhso+4LWn+rsmfqV0w97tB3d6ab5nPBq8WnZhAqxfnq15Skg/YtnavHIx/6nK/Q==@postgresql.org X-Gm-Message-State: AOJu0YwSOP+IPXikdFLUK+JVUe8SN0LBNpJxXMaxZUGFlG3FXF82npBv PcVC6fAh3Dl7UegXkqtHVGj0n6d9LffxRY5nNhvsLS9thnk8AwVXse3xuvJUSLNXNPYuJNzfFdg twk6EtGBjF+wq74FEFJBncV1KduU= X-Google-Smtp-Source: AGHT+IH0QPSDeah9BHaUa+ehhUtQWp6/GO1tji9W57KvErOkYcfWUAaXNwNTixLyNDr3a2Ql2WgVTdHFAVYc1N2JxjA= X-Received: by 2002:a05:651c:506:b0:2fa:d2c3:a7e8 with SMTP id 38308e7fff4ca-2fedb77156cmr68812871fa.13.1730827847173; Tue, 05 Nov 2024 09:30:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Serrano Date: Tue, 5 Nov 2024 14:30:35 -0300 Message-ID: Subject: Re: PostgreSQL historical database To: Samed YILDIRIM Cc: Pgsql-admin , pgsql-admin Content-Type: multipart/alternative; boundary="000000000000ff8eae06262dc265" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ff8eae06262dc265 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Sirs, I'll tell you a little about what I need. Normally, during the day, records are made or recorded in the main database, which at the end of the day are consolidated (accounting closings) and are recorded in the database. In order not to make the main database grow without measure (which will only maintain the range between 3 months to 1 year). For this reason, this data must be transferred to another database so that it lasts over time and can be consulted by other areas. (This action is done humanly every day of the year at the end of the day) Therefore, the project seeks to be able to carry out this extraction of the consolidated data to another database, but automatically. I was thinking of doing this with some triggers or with jobs that allow me to carry out these actions. I also thought of creating a replication of only the consolidated tables to the new historical database server, but I have not yet defined the method. That's why I need to know if there is a tool that allows me to create this database. I hope this clarifies a little the scope of the new historical database. Thank you very much in advance Regards *Erik R. Serrano Saavedra* * Data Base Administrator* El mar, 5 nov 2024 a las 12:37, Samed YILDIRIM () escribi=C3=B3: > Hello Erik, > > It is not very clear for me what you are looking for. But, pg_bitemporal > may be answer for you. I recommend to you to check the repository below. = If > this is not what you want, can you elaborate a little more? > > https://github.com/hettie-d/pg_bitemporal > > Best regards. > Samed YILDIRIM > > On Tue, 5 Nov 2024, 17:31 Erik Serrano, wrote: > >> Dear, >> >> Along with greetings, I would like to ask if there is any product, way >> (architecture), system that allows me to create a historical database fr= om >> a main transactional database in PostgreSQL. >> >> I thank you in advance for any contributions that help me to approach >> this new project. >> >> Thank you very much, Guys, >> Regards >> >> >> >> *Erik R. Serrano Saavedra* >> * Data Base Administrator* >> >> > --000000000000ff8eae06262dc265 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= div dir=3D"ltr">
Dear Sirs,

I'll tell you a little about wha= t I need. Normally, during the day, records are made or recorded in the mai= n database, which at the end of the day are consolidated (accounting closin= gs) and are recorded in the database. In order not to make the main databas= e grow without measure (which will only maintain the range between 3 months= to 1 year). For this reason, this data must be transferred to another data= base so that it lasts over time and can be consulted by other areas. (This = action is done humanly every day of the year at the end of the day)
Ther= efore, the project seeks to be able to carry out this extraction of the con= solidated data to another database, but automatically.

I was thinkin= g of doing this with some triggers or with jobs that allow me to carry out = these actions. I also thought of creating a replication of only the consoli= dated tables to the new historical database server, but I have not yet defi= ned the method.

That's why I need to know if there is a tool tha= t allows me to create this database.

I hope this clarifies a little = the scope of the new historical database.

Thank you very much in adv= ance
Regards


Erik R. Serrano Saavedra
=C2=A0 =C2=A0 =C2=A0 Data Base Administrator<= /i>



El mar, 5 nov 2024 a las 12:37, S= amed YILDIRIM (<samed@reddoc.net= >) escribi=C3=B3:
Hello Erik,

It is not very clear for me what you are looking for. But, = pg_bitemporal may be answer for you. I recommend to you to check the reposi= tory below. If this is not what=C2=A0you want, can you elaborate a little= =C2=A0more?


Best regards.
Sa= med YILDIRIM

On Tue, 5 Nov 2024, 17:31 Erik Serrano, <eserranos@gmail.com> wro= te:
Dear,

Along with greetings, I would like to ask if there i= s any product, way (architecture), system that allows me to create a histor= ical database from a main transactional database in PostgreSQL.

I th= ank you in advance for any contributions that help me to approach this new = project.

Thank you very much, Guys,
Regards



Erik R. Serrano Saavedra
=C2=A0 =C2=A0 =C2=A0=C2=A0Data Base Administrator
=C2=A0
--000000000000ff8eae06262dc265--