performance expectations for table(s) with 2B recs - Mailing list pgsql-general

From David Gauthier
Subject performance expectations for table(s) with 2B recs
Date
Msg-id CAMBRECAWFQ+o+Bmt4jXpGC++gM_VQBTZURNbvB=7L1OEjVvg3A@mail.gmail.com
Whole thread Raw
Responses Re: performance expectations for table(s) with 2B recs  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Re: performance expectations for table(s) with 2B recs  (Marc Millas <marc.millas@mokadb.com>)
List pgsql-general
11.5 on linux
server = VM provided by our IT dept (IOW, can be grown if needed)
DB itself is on NFS

So far, the tables I have in my DB have relatively low numbers of records (most are < 10K, all are < 10M).  Things have been running great in terms of performance.  But a project is being brainstormed which may require some tables to contain a couple billion records.

I'm familiar with the need to properly index columns in these tables which will be used for table joining and query performance (candidates are columns used in query predicate, etc...).  Let's assume that's done right.  And let's assume that the biggest table will have 20 varchars (<= 16 chars per) and 20 ints.  No blobs or jsonb or anything like that.  

What else should I be worried about ?

I suspect that part of why things are running really well so far is that the relatively small amounts of data in these tables ends up in the DB cache and disk I/O is kept at a minimum.  Will that no longer be the case once queries start running on these big tables ?

What about DBA stuff... vacuum and fragmentation and index maintenance, etc... ?

I don't want to step into this completely blind.  Any warnings/insights would be appreciated.

pgsql-general by date:

Previous
From: Roxanne Reid-Bennett
Date:
Subject: Re: How to allow null as an option when using regexp_matches?
Next
From: "Peter J. Holzer"
Date:
Subject: Re: performance expectations for table(s) with 2B recs