Search Postgresql Archives

Re: Plans for partitioning of inheriting tables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Adrian Klaver <adrian.klaver@xxxxxxxxxxx> 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 trying to convince anyone to do anything about the implementation of declarative partitioning. I have been just curious if there were plans. If I have raised the impression of the former, I am sorry.

What I getting at is that you need to start thinking of another way of doing this if this is a current project. The choices are:

1) Declarative partitioning, where you cannot have your partition parent inherit from another table.

2) Partition by inheritance where you build the structure manually.

I very much agree. Shying the effort involved for 2), I still tend to 1). I could break the inheritance pattern by explicitly putting the technical attributes into partitioned tables. My self, I probably won't use more than one source, but others might have several source for comparison or whatever.

Is there experience on the efficiency/speed comparing partitioning with inheritance using triggers/rules and using the declarative way? I don't think that partition speed is an issue in my case, as I have fairly few records that are in themselves rather big.

Hard to say without some firm numbers and/or testing.

Sure, I was hoping those test would have been done some day. But in the end, to me, it is not important.

Also this "... I have fairly few records that are in themselves rather big" could use some explanation. In other words what makes you think that partitioning is the answer to this issue?

I was not thinking that partitioning was the answer to a performance problem. Partitioning might be an answer to the maintenance of records, specifically if entire sources are affected. The size of the tif files to get loaded into the raster attribute TILE range from 112 kB to 32 MB. I am complete unaware of the inner storing mechanisms of raster in PostGIS, but on first sight, it seems that the rest of a records of TOPO_FILES is negligible compared to the TILE. The total number of files to be loaded in my case are 3273, even though that only encompasses a small part of the world, I do not think, the latter would surpass 100000 records. Not much for a database table, afaik. I mean to say that I believe that loading that much data into one field will take much more time than runtime difference of trigger/rules/declarative partitioning solutions would to sort the data into the correct partition.






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux