On 5/23/23 13:58, Christoph Moench-Tegeder wrote:
## Ron (ronljohnso...@gmail.com):
We'd never hardlink. Eliminates the ability to return to the old
system if something goes wrong.
That's why you get yourself a recent XFS and use clone mode (still
sticks you to the same filesystem, but gets y
On 2023-05-23 13:17:24 -0500, Ron wrote:
> On 5/23/23 12:19, Peter J. Holzer wrote:
> > On 2023-05-22 21:10:48 -0500, Ron wrote:
> > > On 5/22/23 18:42, Tom Lane wrote:
> > > > It looks like the assumption was that issuing link()
^^
> > > >
## Ron (ronljohnso...@gmail.com):
> We'd never hardlink. Eliminates the ability to return to the old
> system if something goes wrong.
That's why you get yourself a recent XFS and use clone mode (still
sticks you to the same filesystem, but gets you up running much
faster).
Regards,
Christoph
On 5/23/23 12:19, Peter J. Holzer wrote:
On 2023-05-22 21:10:48 -0500, Ron wrote:
On 5/22/23 18:42, Tom Lane wrote:
It looks like the assumption was that issuing link()
requests in parallel wouldn't help much but just swamp your disk
if they're all on the same filesystem.
Maybe that could use r
On 2023-05-22 21:10:48 -0500, Ron wrote:
> On 5/22/23 18:42, Tom Lane wrote:
> > It looks like the assumption was that issuing link()
> > requests in parallel wouldn't help much but just swamp your disk
> > if they're all on the same filesystem.
> > Maybe that could use rethinking, not sure.
>
> I
Hi,
Our developers do their work using a local PostgreSQL database server and local
schemas.
This is typically done by installing the Windows version of the PostgreSQL
installer from EnterpriseDB. Currently, version 13.4 (64-bit) of the installer
is being used.
Recently, our organization has
On Sun, 2023-05-21 at 07:56 -0700, Mike Lissner wrote:
> > As far as I know it's impossible to reliably pg_upgrade a node
> > that has subscriptions and eventually resume logical
> > replication.
> >
>
>
> Should this go in the documentation somewhere? Maybe in the
> pg_upgrade notes? I still d
Hi!
Using index
create index on toode ( *split_part( toode, '/',1) *)
and query
select toode.toode , n2, n3, n4
from toode, vordlusajuhinnak
where *split_part( toode.toode, '/',1) *= vordlusajuhinnak.toode;
reduces run time to 5 minutes.
Andrus.
23.05.2023 17:26 Andrus kirjutas:
Hi!
On 5/22/23 5:43 PM, Adrian Klaver wrote:
From docs:
https://www.postgresql.org/docs/current/pgupgrade.html
The --jobs option allows multiple CPU cores to be used for
copying/linking of files and to dump and restore database schemas in
parallel; a good place to start is the maximum of the n
On 5/22/23 5:42 PM, Tom Lane wrote:
Jeff Ross writes:
On 5/22/23 5:24 PM, Adrian Klaver wrote:
So is the 1400G mostly in one database in the cluster?
Yes, one big database with about 80 schemas and several other smaller
databases so -j should help, right?
AFAICT from a quick look at the co
Hi!
Separate
the product code and size into two columns --- if there's somebody
who really wants to see them in the above format, give them a
view or generated column. Then instead of the impossible-to-optimize
queries you showed, you could do something like
select toode.toode , n2, n3, n4
fro
Andrus writes:
> Product table as both main products and subproducts with sizes. Size is
> separated by main product code always by / character:
> SHOE1-BLACK
> SHOE1-BLACK/38
> SHOE1-BLACK/41
> SHOE1-BLACK/42
> SHOE1-BLACK/43
> SHOE2/XXL
> SHOE2/L
You could p
Hi!
I ran
analyze toode;
create index vordlusajuhinnak_toode_pattern_idx on
vordlusajuhinnak(toode bpchar_pattern_ops);
create index vordlusajuhinnak_toode_idx on vordlusajuhinnak(toode);
analyze vordlusajuhinnak;
Select runs now more than one hour. Output from explain
explain create table
Greetings,
There seems to be a bit of confusion here, so I'll try to clear it up.
* Tony Xu (tony...@rubrik.com) wrote:
> Thanks all for the discussions. It sounds like there are different
> questions to clear before we can get to a conclusion on if per-database KEK
> is possible or not.
It's no
14 matches
Mail list logo
