>
>
>From: Peter J. Holzer hjp-pg...@hjp.at<mailto:hjp-pg...@hjp.at>
>Sent: Friday, December 10, 2021 3:43 PM
>To:
>pgsql-general@lists.postgresql.org<mailto:pgsql-general@lists.postgresql.org>
>Subject: Re: [EXTERNAL] Re: performance expectations for table(s) wi
On 2021-12-10 18:04:07 +, Godfrin, Philippe E wrote:
> >But in my experience the biggest problem with large tables are unstable
> >execution plans - for most of the parameters the optimizer will choose
> >to use an index, but for some it will erroneously think that a full
> >table scan is faste
On 2021-12-08 14:44:47 -0500, David Gauthier wrote:
> 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
> t
Partitioning ?
if you have some ideas about how this data is accessed, splitting those
big tables into partitions may help:
-vaccum done at the partition level,
-index partitioned too, so much easier to manage (reindex local to a given
partition, so quite easy to reindex the whole thing one partit
On 2021-12-08 14:44:47 -0500, David Gauthier wrote:
> 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
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 brainstorm
