public inbox for [email protected]  
help / color / mirror / Atom feed
Re: DB Files
2+ messages / 2 participants
[nested] [flat]

* Re: DB Files
@ 2024-11-15 15:47  Adrian Klaver <[email protected]>
  0 siblings, 1 reply; 2+ messages in thread

From: Adrian Klaver @ 2024-11-15 15:47 UTC (permalink / raw)
  To: Andy Hartman <[email protected]>; [email protected] <[email protected]>

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:
> 
> 2474695.143
> 
> They are all 1,048,576kb
> 
> Is this normal behaviour and could I have done something to use fewer 
> files and larger ones?

Read:

https://www.postgresql.org/docs/current/storage-file-layout.html

[...]

"When a table or index exceeds 1 GB, it is divided into gigabyte-sized 
segments. The first segment's file name is the same as the filenode; 
subsequent segments are named filenode.1, filenode.2, etc. This 
arrangement avoids problems on platforms that have file size 
limitations. (Actually, 1 GB is just the default segment size. The 
segment size can be adjusted using the configuration option 
--with-segsize when building PostgreSQL.) In principle, free space map 
and visibility map forks could require multiple segments as well, though 
this is unlikely to happen in practice."

[...]

> 
> 
> This table is created in a separate tablespace on a dedicated drive on 
> the windows file system.
> 
>   I'm just getting involved in this PostgreSql instance
> 
> THanks.

-- 
Adrian Klaver
[email protected]







^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: DB Files
@ 2024-11-15 15:49  Andy Hartman <[email protected]>
  parent: Adrian Klaver <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Andy Hartman @ 2024-11-15 15:49 UTC (permalink / raw)
  To: Adrian Klaver <[email protected]>; +Cc: [email protected] <[email protected]>

Thanks... I just found that myself... so normal behavior then...

On Fri, Nov 15, 2024 at 10:47 AM Adrian Klaver <[email protected]>
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 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 normal behaviour and could I have done something to use fewer
> > files and larger ones?
>
> Read:
>
> https://www.postgresql.org/docs/current/storage-file-layout.html
>
> [...]
>
> "When a table or index exceeds 1 GB, it is divided into gigabyte-sized
> segments. The first segment's file name is the same as the filenode;
> subsequent segments are named filenode.1, filenode.2, etc. This
> arrangement avoids problems on platforms that have file size
> limitations. (Actually, 1 GB is just the default segment size. The
> segment size can be adjusted using the configuration option
> --with-segsize when building PostgreSQL.) In principle, free space map
> and visibility map forks could require multiple segments as well, though
> this is unlikely to happen in practice."
>
> [...]
>
> >
> >
> > This table is created in a separate tablespace on a dedicated drive on
> > the windows file system.
> >
> >   I'm just getting involved in this PostgreSql instance
> >
> > THanks.
>
> --
> Adrian Klaver
> [email protected]
>
>


^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2024-11-15 15:49 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-11-15 15:47 Re: DB Files Adrian Klaver <[email protected]>
2024-11-15 15:49 ` Andy Hartman <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox