Greetings,
* Piotr Włodarczyk (piotrwlodarczy...@gmail.com) wrote:
> We met unexpected PostgreSQL shutdown. After a little investigation we've
> discovered that problem is in OOM killer which kills our PostgreSQL.
You need to configure your system to not overcommit.
Read up on overcommit_ratio a
Greetings,
* Arya F (arya6...@gmail.com) wrote:
> > * Arya F (arya6...@gmail.com) wrote:
> > > I need to store about 600 million rows of property addresses across
> > > multiple counties. I need to have partitioning setup on the table as
> > > there will be updates and inserts performed to the tab
Greetings,
* Arya F (arya6...@gmail.com) wrote:
> I need to store about 600 million rows of property addresses across
> multiple counties. I need to have partitioning setup on the table as
> there will be updates and inserts performed to the table frequently
> and I want the queries to have good p
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Turns out to be because what was provided wasn't actually what was being
> > used- there's a domain in there and that seems to gum up the works and
> > make it so we don't consider
Greetings,
* Jeff Janes (jeff.ja...@gmail.com) wrote:
> In order to read 1409985 / 12839 = 109 rows per buffer page, the table must
> be extraordinarily well clustered on this index. That degree of clustering
> is going to steal much of the thunder from the index-only scan. But in my
> hands, it
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I do wonder if we are maybe missing a bet at times though, considering
> > that I'm pretty sure we'll always go through the index in order, and
> > therefore randomly, even when we don
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Thu, Apr 23, 2020 at 8:29 AM Tom Lane wrote:
> > "David G. Johnston" writes:
> > > On Thursday, April 23, 2020, Thomas Kellerer wrote:
> > >> Plus: scanning idx_tabla_entidad is more efficient because that index is
> > >> s
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> "David G. Johnston" writes:
> > On Thursday, April 23, 2020, Thomas Kellerer wrote:
> >> Plus: scanning idx_tabla_entidad is more efficient because that index is
> >> smaller.
>
> > Really? The absence of 33 million rows in the partial index
Greetings,
* Fabio Pardi (f.pa...@portavita.eu) wrote:
> I understand that in this thread we are contextualizing in a step by
> step procedure to create a new standby, but I have anyway a few remarks
> about it (and the documentation where it has been copied from) and I
> would be glad if you or s
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Jun 14, 2019 at 10:39:40AM -0400, Bruce Momjian wrote:
> > On Fri, Jun 14, 2019 at 03:12:29PM +0200, Fabio Pardi wrote:
> > > Using --size-only, tells rsync to only check the size of the blocks.
> > > That is: if the block is present o
Greetings,
* Haroldo Kerry (hke...@callix.com.br) wrote:
> The bottleneck at dump is CPU (a single one, on a 44 thread server), as we
> are using the -Fc option, that does not allow multiple jobs.
> We tried some time ago to use the --jobs option of pg_dump but it was
> slower, even with more thre
Greetings,
* Lev Kokotov (lev.koko...@gmail.com) wrote:
> Is it efficient to use Postgres as a column store by creating one table per
> column?
Short answer is no, not in a traditional arrangement, anyway. The tuple
overhead would be extremely painful. It's possible to improve on that,
but it r
Greetings,
Please don't post these kinds of questions to this list, it's not the
right list.
Pick the correct list to use in the future, and don't cross-post to
multiple lists.
This list is specifically for performance issues and questions regarding
PostgreSQL, not about how to upgrade. For tha
Greetings,
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Tue, Nov 20, 2018 at 11:28 AM Stephen Frost wrote:
> > Oh yes, having a dictionary would be a great start to reducing the size
> > of the jsonb data, though it could then become a contention point if
> > there&
Greetings,
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Tue, Nov 20, 2018 at 10:43 AM Stephen Frost wrote:
> > * Merlin Moncure (mmonc...@gmail.com) wrote:
> > > On Mon, Nov 19, 2018 at 11:26 AM Stephen Frost wrote:
> > > > Looks like a lot of the differen
Greetings,
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Mon, Nov 19, 2018 at 11:26 AM Stephen Frost wrote:
> > Looks like a lot of the difference being seen and the comments made
> > about one being faster than the other are because one system is
> > compressing *
Greetings,
* Fabio Pardi (f.pa...@portavita.eu) wrote:
> thanks for your feedback.
We prefer on these mailing lists to not top-post but instead to reply
inline, as I'm doing here. This helps the conversation by eliminating
unnecessary dialogue and being able to make comments regarding specific
p
Greetings,
* Fabio Pardi (f.pa...@portavita.eu) wrote:
> We are open to any kind of feedback and we hope you enjoy the reading.
Looks like a lot of the difference being seen and the comments made
about one being faster than the other are because one system is
compressing *everything*, while PG (q
Greetings,
These questions are not appropriate for the 'performance' mailing list
but should be either on 'admin' or 'general'. Please use the
appropriate list for asking questions in the future.
* Rambabu V (ram.wis...@gmail.com) wrote:
> Please help us to get the query log details from meta da
Greetings,
* Rambabu V (ram.wis...@gmail.com) wrote:
> by mistake one physical file dropped for one of our table, as we do-not
> have backup for this table we are getting below error.
>
> ERROR: could not open file "base/12669/16394": No such file or directory
>
> please help us to recover the
Greetings,
* l...@laurent-hasson.com (l...@laurent-hasson.com) wrote:
> > * l...@laurent-hasson.com (l...@laurent-hasson.com) wrote:
> > > This was done during a maintenance window, and that table is read-only
> > except when we ETL data to it on a weekly basis, and so I was just wondering
> > why
Greetings,
* l...@laurent-hasson.com (l...@laurent-hasson.com) wrote:
> This was done during a maintenance window, and that table is read-only except
> when we ETL data to it on a weekly basis, and so I was just wondering why I
> should pay the "bloat" penalty for this type of transaction. Is th
Greetings!
This list has now been migrated to new mailing list software known as
'PGLister'. This migration will impact all users of this mailing list
in one way or another.
If you would like to unsubscribe from this mailing list, please click on
'Show Original' or 'Show Headers' in your client
23 matches
Mail list logo
