On 11/1/24 16:10, thi...@gelassene-pferde.biz wrote:
Adrian Klaver escribió:
On 11/1/24 13:47, Thiemo Kellner wrote:
It looks to me basically to be a "create table A as select * from B
where false".
No it more capable then that.
Yes, I wrote basically, not exactly.
CREATE TABLE LIKE h
Adrian Klaver escribió:
On 11/1/24 13:47, Thiemo Kellner wrote:
It looks to me basically to be a "create table A as select * from B
where false".
No it more capable then that.
Yes, I wrote basically, not exactly.
CREATE TABLE LIKE has like_option which
allows to transfer over more
On 11/1/24 13:47, Thiemo Kellner wrote:
It looks to me basically to be a "create table A as select * from B where
false".
No it more capable then that.
CREATE TABLE AS is bare bones, you get the
column names, types and data(or not) and that is it.
CREATE TABLE LIKE has like_option whi
It looks to me basically to be a "create table A as select * from B where
false".
01.11.2024 20:38:15 Adrian Klaver :
> On 11/1/24 12:16, thi...@gelassene-pferde.biz wrote:
>> Thanks, I shall have a look into it. I was under the assumption the the
>> create table like would create no more than
On 2024-10-27 16:23:44 +0100, Costa Alexoglou wrote:
> The container limit was 16GB of RAM, and as soon as this limit was reached,
> there was no restart or OOM errors, rather than a huge drop in memory (image
> `ContainerRelativeAbsolute`).
[...]
> 2. What is happening on the OS level when suddenl
On 11/1/24 12:16, thi...@gelassene-pferde.biz wrote:
Thanks, I shall have a look into it. I was under the assumption the the
create table like would create no more than a structural copy.
Not sure what you mean by structural copy, but the table created by
CREATE TABLE LIKE will not have any as
Thanks, I shall have a look into it. I was under the assumption the
the create table like would create no more than a structural copy.
Torsten F��rtsch escribi��:
Thiemo, ��
it looks to me like you are using inheritance just to make sure
your SOURCES and TOPO_FILES tables have som
Adrian Klaver escribió:
Even if there where plans, any changes would happen in the future
and would not be help the now problem.
Yes and no. I can live without the partitioning, as I do not intend to
load data from more than one source. Other might. But until others
want to load data f
Thiemo,
it looks to me like you are using inheritance just to make sure your
SOURCES and TOPO_FILES tables have some common columns. If you are not
actually querying the TEMPLATE_TECH table and expect to see all the rows
from the other 2 tables in that one table combined, then you could use
CREATE
On 11/1/24 10:21 AM, thi...@gelassene-pferde.biz wrote:
Adrian Klaver escribió:
Changing that would count as a major change. Even if you where to
convince the developers to make the change the earliest it would
released would be with the next major release in Fall of 2025. That
assumes y
Adrian Klaver escribió:
Changing that would count as a major change. Even if you where to
convince the developers to make the change the earliest it would
released would be with the next major release in Fall of 2025. That
assumes you can convince then early enough or at all.
I was not
On 11/1/24 01:41, thi...@gelassene-pferde.biz wrote:
Adrian Klaver escribió:
It is just not the way you want to do it, see:
https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITIONING-USING-INHERITANCE
Thanks for your patience. Maybe I am not clever enough to understand
On 10/24/24 21:58, David G. Johnston wrote:
On Thursday, October 24, 2024, wrote:
Up to version 17, partitioning of tables inheriting from other
tables is not possible.
psql:../code_files/data_storage/PostgreSQL/tables/TOPO_FILES.pg_sql:68:
ERROR: no se puede crear u
Hello Adrian,
My apology for answering so late.
Indeed I have not splitted my transactions correctly in my first example.
BUT, if you change the syntaxt so that attach is performed in its own
transaction, result is the same. Try it out!
Also you have told me that I am seeing ExclusiveLock on refs
On Fri, Nov 1, 2024 at 2:40 AM Muhammad Usman Khan
wrote:
> For immediate space, move older files from pg_Wal to another storage but
> don't delete them.
>
No, do not do this! Figure out why WAL is not getting removed by Postgres
and let it do its job once fixed. Please recall the original poste
Adrian Klaver escribió:
It is just not the way you want to do it, see:
https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITIONING-USING-INHERITANCE
Thanks for your patience. Maybe I am not clever enough to understand
you. I shall try to explain what I try to do.
In
16 matches
Mail list logo
