On Tue, 15 Jul 2025, Thom Brown wrote:
UPDATE companies
SET company_name = rtrim(company_name, '.')
WHERE company_name != rtrim(company_name, '.');
Thom,
That makes sense. The web pages I read assumed I knew to use the UPDATE
command. As this was the first time I needed to clean column conten
On Tue, 15 Jul 2025, 18:59 Rich Shepard, wrote:
> On Tue, 15 Jul 2025, Thom Brown wrote:
>
> > There are various options, but perhaps just use rtrim.
> > rtrim(company_name, '.')
>
> Thom,
>
> I looked at rtrim() but didn't see where to specify the table name. Would
> it
> be `select * from table
Hi Kiran,
Are we trying to perform logical replication from create replication slots on a
standby server and use logical decoding plugins(JDBC PGReplicationStream API)
to stream changes from the standby
Is my understanding correct?
Hi,
I have a question regarding the new featu
On Tue, 15 Jul 2025, Jeff Ross wrote:
How about
test:
select company_name, replace(company_name,'.','') from companies;
update:
update companies set company_name = replace(company_name,'.','') where
company_name like '%.';
Jeff,
These contain the table and column names I didn't see
On Tue, 15 Jul 2025, Thom Brown wrote:
There are various options, but perhaps just use rtrim.
rtrim(company_name, '.')
Thom,
I looked at rtrim() but didn't see where to specify the table name. Would it
be `select * from table companies rtrim(company_name, '.')'?
Thanks,
Rich
On Tue, 15 Jul 2025, 18:30 Rich Shepard, wrote:
> I want to remove the terminal period '.' from the varchar strings in the
> 'company_name' column in all rows with that period in the companies table.
>
> I've looked at trim(), translate(), "substr(company_name 1,
> length(compan_name) - 1)", and
On 7/15/25 11:30, Rich Shepard wrote:
I want to remove the terminal period '.' from the varchar strings in the
'company_name' column in all rows with that period in the companies
table.
I've looked at trim(), translate(), "substr(company_name 1,
length(compan_name) - 1)", and a couple of othe
On Mon, Jul 14, 2025 at 2:01 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Jul 14, 2025 at 12:54 PM Adrian Klaver
> wrote:
>
>> On 7/14/25 12:51, veem v wrote:
>> > So I want to
>> > understand the experts' opinion on this which I believe will be
>> > crucial during design
I want to remove the terminal period '.' from the varchar strings in the
'company_name' column in all rows with that period in the companies table.
I've looked at trim(), translate(), "substr(company_name 1,
length(compan_name) - 1)", and a couple of other functions and am unsure how
best to do t
if I "alter table allwise set (parallel_workers = 64);" then I can get 64
workers. I wonder if the code
to check the rel_parallel_workers do deal with the default algorithm not
allocating sufficient
parallel_workers.
On Mon, Jul 14, 2025 at 2:54 PM Tom Lane wrote:
> Greg Hennessy writes:
> >>
You might want to examine the SKIP LOCKED feature as well, if you are using
this query to have multiple workers grab chunks of the table to work on
concurrently.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
Laurenz Albe writes:
> Text is easier to read than images...
Indeed.
> Anyway, this statement was done in under a millisecond.
> I wouldn't call that slow...
It looks to me like this EXPLAIN ANALYZE was done against a totally
empty table, so probably in a freshly-set-up dev environment. That
i
On Tue, 2025-07-15 at 18:26 +0530, Durgamahesh Manne wrote:
> On Tue, Jul 15, 2025 at 6:14 PM Laurenz Albe wrote:
> > On Tue, 2025-07-15 at 15:40 +0530, Durgamahesh Manne wrote:
> > > We are facing issues with slow running query
> > > SELECT betid, versionid, betdata, processed, messagetime, c
Can you try like: ORDER BY betid desc
---Original---
From: "Durgamahesh Manne"
0D59E1CB@A7AE4F48.30527668.png
Description: Binary data
On Tue, Jul 15, 2025 at 6:14 PM Laurenz Albe
wrote:
> On Tue, 2025-07-15 at 15:40 +0530, Durgamahesh Manne wrote:
> > We are facing issues with slow running query
> >SELECT betid, versionid, betdata, processed, messagetime, createdat,
> updatedat
> >FROM praermabetdata where processed = '
On Tue, 2025-07-15 at 15:40 +0530, Durgamahesh Manne wrote:
> We are facing issues with slow running query
> SELECT betid, versionid, betdata, processed, messagetime, createdat,
> updatedat
>FROM praermabetdata where processed = 'false'
>ORDER BY betid, versionid LIMIT 200 OFFSET 0 FOR
On Tue, 15 Jul 2025, Laurenz Albe wrote:
Apart from that, the subquery seems to be missing a GROUP BY clause.
Laurenz,
That was added.
Thanks,
Rich
Thanks Tom and Laurenz for the explanation.
Let me try out a few things and get back to you if needed.
Thanks,
Amol
On Mon, Jul 14, 2025 at 7:37 PM Tom Lane wrote:
> Laurenz Albe writes:
> > It is not a good idea to have a mount point be the data directory.
>
> ^^^ This. ^^^
>
> That is primar
Thanks Laurenz.
On Mon, Jul 14, 2025 at 8:11 PM Laurenz Albe
wrote:
> On Mon, 2025-07-14 at 18:32 +0530, Amol Inamdar wrote:
> > > The data directory can either be created by "initdb", in which case
> > > the mount point must allow the PostgreSQL user to create a directory.
> > > You could set t
Hi Team,
We are facing issues with slow running query
SELECT betid, versionid, betdata, processed, messagetime, createdat,
updatedat FROM praermabetdata where processed = 'false' ORDER BY betid,
versionid LIMIT 200 OFFSET 0 FOR UPDATE;
Q
20 matches
Mail list logo
