Re: DB Files

2024-11-15 Thread Andy Hartman
Thanks... I just found that myself... so normal behavior then... On Fri, Nov 15, 2024 at 10:47 AM Adrian Klaver wrote: > On 11/15/24 06:27, Andy Hartman wrote: > > I created a new table (V16) and then used SimplySql to take data from > > mssql to the new Postgres table. The table is 212gig in s

Re: DB Files

2024-11-15 Thread Torsten Förtsch
PG normally splits table data into 1GB chunks. The number before the dot is called the filenode. You can translate it into a table name by select oid::regclass::text from pg_class where relfilenode='2474695'; I believe there is an option to change that chunk size but you'd have to recompile Postg

Re: DB Files

2024-11-15 Thread Adrian Klaver
On 11/15/24 06:27, Andy Hartman wrote: I created a  new table (V16) and then used SimplySql to take data from mssql to the new Postgres table. The table is 212gig in size. Myquestion comes from the files created on the OS(Windows2022 server) I can see lots of files with the last being: 247469

DB Files

2024-11-15 Thread Andy Hartman
I created a new table (V16) and then used SimplySql to take data from mssql to the new Postgres table. The table is 212gig in size. Myquestion comes from the files created on the OS(Windows2022 server) I can see lots of files with the last being: 2474695.143 They are all 1,048,576kb Is this nor

Re: fdatasync performance problem with large number of DB files

2021-02-23 Thread Michael Brown
On 2021-02-22 5:43 p.m., Tom Lane wrote: > Michael Brown writes: >> * is there a knob missing we can configure? > > No. The trouble with sync() is that per POSIX, it only schedules the > writes; there's no way to tell when the work has been done. I see > that Linux offers stronger promises in t

Re: fdatasync performance problem with large number of DB files

2021-02-22 Thread Tom Lane
Michael Brown writes: > I presume the reason postgres doesn't blindly run a sync() is that we > don't know what other I/O is on the system and it'd be rude to affect > other services. That makes sense, except for our environment the work > done by the recursive fsync is orders of magnitude more di

fdatasync performance problem with large number of DB files

2021-02-22 Thread Michael Brown
We've encountered a production performance problem with pg13 related to how it fsyncs the whole data directory in certain scenarios, related to what Paul (bcc'ed) described in a post to pgsql-hackers [1]. Background: We've observed the full recursive fsync is triggered when * pg_basebackup recei