> On Dec 9, 2024, at 03:02, Lars Aksel Opsahl wrote:
> If there were a way to remove dead rows without requiring a commit from
> totally unrelated jobs, it would be much easier.
Without seeing into the future, PostgreSQL doesn't know if a particular open
transaction is "totally unrelated" to
> On Aug 4, 2021, at 08:06, Nikhil Shetty wrote:
>
> How can we increase the speed of the initial data load without dropping the
> indexes on destination?
You can do the usual steps of increasing checkpoint_timeout and max_wal_size
(since incoming logical replication changes are WAL logged)
> On Jul 11, 2021, at 17:36, Nagaraj Raj wrote:
>
> personally, I feel this design is very bad compared to other DB servers.
Patches accepted. The issue is that in order to have a partition-set-wide
unique index, the system would have to lock the unique index entries in *all*
partitions, n
> On Jul 8, 2021, at 20:32, Nagaraj Raj wrote:
>
> My apologies for making confusion with new thread. Yes its same issue related
> to earlier post.
>
> I was trying to figure out how to ensure unique values for columns
> (billing_account_guid, ban). If i add partition key to constraint , i
> On Jun 8, 2021, at 09:03, Ayub Khan wrote:
> I checked all the indexes are defined on the tables however the query seems
> slow, below is the plan.
It's currently running in slightly under six milliseconds. That seems
reasonably fast given the number of operations required to fulfill it.
> On Jun 6, 2021, at 21:51, Ayub Khan wrote:
> Other than Dexter, Is there an auto tune or query performance indicator for
> postgres ?
Generally, auto-creating indexes isn't a great idea. I respect the work that
went into Dexter, but it's much better to find the queries and study them, the
> On May 30, 2021, at 20:07, Dean Gibson (DB Administrator)
> wrote:
> The first two JOINs are not the problem, & are in fact retained in my
> solution. The problem is the third JOIN, where "fips_county" from "County"
> is actually matched with the corresponding field from the "zip_code" VI
> On May 28, 2021, at 14:30, Bruce Momjian wrote:
> I think it uses pg_upgrade.
It does. It does not, however, do the vacuum analyze step afterwards. A
VACUUM (FULL, ANALYZE) should take care of that, and I believe the OP said he
had done that after the pg_upgrade.
The most common reason
> On May 25, 2021, at 17:16, David Rowley wrote:
>
> It's because of the OR condition. If it was an AND condition then the
> planner wouldn't have to consider the fact that records in other
> partitions might be required for the join.
The OP might consider rewriting the query as a UNION, wit
> On May 25, 2021, at 15:50, Nagaraj Raj wrote:
>
> SELECT
> t2.cid_hash AS BILLG_ACCT_CID_HASH ,
> t2.proxy_id AS INDVDL_ENTITY_PROXY_ID ,
> t2.accs_mthd AS ACCS_MTHD_CID_HASH
> FROM
> public.sub t2
> Inner join acc t3 on t3.cid_hash = t2.cid_hash
> Left join
> On May 24, 2021, at 09:22, Bob Jolliffe wrote:
>
> It is hard to say as it only happens for 30s couple of times per day.
> Everything does return to normal after the blocking transaction is
> committed. It could be a disk thing or even a network issue (the java
> app is on a different machi
> On Apr 24, 2021, at 11:27, Simon Connah wrote:
>
> I'm curious, really. I use btrfs as my filesystem on my home systems and am
> setting up a server as I near releasing my project. I planned to use btrfs on
> the server, but it got me thinking about PostgreSQL 13. Does anyone know if
> it
> On Dec 11, 2020, at 06:34, Atul Kumar wrote:
>
> What do you mean by “how much wal is created”
> How total Wal files in size or how much total wal files in numbers.
Since WAL segment files are a fixed size (almost always 16MB), those numbers
are directly related.
--
-- Chris
13 matches
Mail list logo
