Re: Bloated pg_catalog.pg_largeobjects

[Priancka Chatz]

You have to run vacuumlo to remove orphaned large objects.
https://www.postgresql.org/docs/current/vacuumlo.html

Regards,
Priyanka

On Sun, 21 Jul 2024 at 12:46 AM,  wrote:

> Hello All,
>
> I've got a cluster that's having issues with pg_catalog.pg_largeobject
> getting massively bloated. Vacuum is running OK and there's 700GB of free
> space in the table and only 100GB of data, but subsequent inserts seem to
> be not using space from the FSM and instead always allocating new pages.
> The table just keeps growing.
>
> Is this a known thing, maybe something special about LOs?
>
> Also, is the only way to recover space here a vacuum full on the table
> since it's a catalog table?
>
> Thanks,
> --
> Jon Erdman (aka StuckMojo on IRC)
> PostgreSQL Zealot
>

Windows installation problem at post-install step

[Ertan Küçükoglu]

Hello,



I am trying to install posgreql-16.3-2-windows-x64.exe on Windows 10
English VM with all updates installed and up to date.

During installation I get an error message “Problem running post-install
step. Installation may not complete correctly The database cluster
initialization failed.”



I attached the compressed installation log file just in case. What I see
relevant is below line



The database cluster will be initialized with locale "Turkish_T rkiye.1254".



The cscript command line has all characters correctly logged in UTF8
encoding, but the above is not actually correct. It should read
“Turkish_Türkiye.1254” the “ü” (u with double dot at top) character is not
correct.



I suspect that is the main reason for the cluster creation to fail. I don’t
know how I can manually fix this.



I tried to reach techsupp...@enterprisedb.com but got no response for
almost two weeks now.



Any help would be appreciated.



Thanks & Regards,

Ertan
<>

Re: Windows installation problem at post-install step

[Adrian Klaver]

On 7/21/24 09:16, Ertan Küçükoglu wrote:

Hello,

I am trying to install posgreql-16.3-2-windows-x64.exe on Windows 10 
English VM with all updates installed and up to date.


What is the host OS and version?

What is the locale in the VM?



During installation I get an error message “Problem running post-install 
step. Installation may not complete correctly The database cluster 
initialization failed.”


I attached the compressed installation log file just in case. What I see 
relevant is below line


The database cluster will be initialized with locale "Turkish_Trkiye.1254".

The cscript command line has all characters correctly logged in UTF8 
encoding, but the above is not actually correct. It should read 
“Turkish_Türkiye.1254” the “ü” (u with double dot at top) character is 
not correct.


I suspect that is the main reason for the cluster creation to fail. I 
don’t know how I can manually fix this.


I tried to reach techsupp...@enterprisedb.com 
 but got no response for almost two 
weeks now.


Any help would be appreciated.

Thanks & Regards,

Ertan



--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Windows installation problem at post-install step

[Ertan Küçükoglu]

Adrian Klaver , 21 Tem 2024 Paz, 20:04 tarihinde
şunu yazdı:

> On 7/21/24 09:16, Ertan Küçükoglu wrote:
> > Hello,
> >
> > I am trying to install posgreql-16.3-2-windows-x64.exe on Windows 10
> > English VM with all updates installed and up to date.
>
> What is the host OS and version?
>
> What is the locale in the VM?


Host OS is Windows 11 English. Display language is English. Country is
Türkiye and everything else is set to US English.
I am trying to install PostgreSQL on Windows 10 64bit English. Everything
including the country on the guest OS is also set to US English.

Thanks & Regards,
Ertan

Re: Windows installation problem at post-install step

[Adrian Klaver]

On 7/21/24 10:21, Ertan Küçükoglu wrote:
Adrian Klaver >, 21 Tem 2024 Paz, 20:04 tarihinde 
şunu yazdı:


On 7/21/24 09:16, Ertan Küçükoglu wrote:
 > Hello,
 >
 > I am trying to install posgreql-16.3-2-windows-x64.exe on Windows 10
 > English VM with all updates installed and up to date.

What is the host OS and version?

What is the locale in the VM?


Host OS is Windows 11 English. Display language is English. Country is 
Türkiye and everything else is set to US English.
I am trying to install PostgreSQL on Windows 10 64bit English. 
Everything including the country on the guest OS is also set to US English.


What happens if you set the VM to Türkiye and install?



Thanks & Regards,
Ertan


--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Windows installation problem at post-install step

[Ertan Küçükoglu]

Adrian Klaver , 21 Tem 2024 Paz, 20:34 tarihinde
şunu yazdı:

>
> What happens if you set the VM to Türkiye and install?
>

Problem still exists even if I set everything to Türkiye and Turkish.
1- I tried to manually select default locale to "Turkey, Türkiye"
2- I tried to install using [Default locale]
both of above fails and both installation log files have identical wrong
text "Turkish_T rkiye.1254"

Thanks & Regards,
Ertan

Re: Windows installation problem at post-install step

[Adrian Klaver]

On 7/21/24 10:52, Ertan Küçükoglu wrote:
Adrian Klaver >, 21 Tem 2024 Paz, 20:34 tarihinde 
şunu yazdı:



What happens if you set the VM to Türkiye and install?


Problem still exists even if I set everything to Türkiye and Turkish.
1- I tried to manually select default locale to "Turkey, Türkiye"
2- I tried to install using [Default locale]
both of above fails and both installation log files have identical wrong 
text "Turkish_T rkiye.1254"


I don't know enough about Windows locales and the EDB installer to be of 
further help in that direction.


Is it feasible to install a Linux VM and install Postgres there?



Thanks & Regards,
Ertan


--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Windows installation problem at post-install step

[Ertan Küçükoglu]

Adrian Klaver , 21 Tem 2024 Paz, 21:48 tarihinde
şunu yazdı:

> I don't know enough about Windows locales and the EDB installer to be of
> further help in that direction.
>
> Is it feasible to install a Linux VM and install Postgres there?
>

My main purpose was and still is to reach EDB people using the forum and
let them know about the problem.
I believe it is something to be fixed for future installations. I would
like to provide additional information if needed.

On the other hand, I have a backup taken on another Windows system that I
need to restore after installation.
I am not sure if it will be restored without any issues if I am to use a
Linux VM. I will try.

Thanks for the help.

Regards,
Ertan

Re: Windows installation problem at post-install step

[Adrian Klaver]

On 7/21/24 12:00, Ertan Küçükoglu wrote:
Adrian Klaver >, 21 Tem 2024 Paz, 21:48 tarihinde 
şunu yazdı:


I don't know enough about Windows locales and the EDB installer to
be of
further help in that direction.

Is it feasible to install a Linux VM and install Postgres there?


My main purpose was and still is to reach EDB people using the forum and 
let them know about the problem.
I believe it is something to be fixed for future installations. I would 
like to provide additional information if needed.


You could try a back door method and post here:

https://www.postgresql.org/list/pgadmin-support/

pgAdmin comes from EDB also, maybe someone on that list could pass your 
issue on.




On the other hand, I have a backup taken on another Windows system that 
I need to restore after installation.
I am not sure if it will be restored without any issues if I am to use a 
Linux VM. I will try.


If the backup was done using pg_dump it should work. If you are talking 
about a file level backup then it would not work.




Thanks for the help.

Regards,
Ertan



--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Windows installation problem at post-install step

[Thomas Munro]

On Mon, Jul 22, 2024 at 7:29 AM Adrian Klaver  wrote:
> On 7/21/24 12:00, Ertan Küçükoglu wrote:
> > My main purpose was and still is to reach EDB people using the forum and
> > let them know about the problem.
> > I believe it is something to be fixed for future installations. I would
> > like to provide additional information if needed.
>
> You could try a back door method and post here:
>
> https://www.postgresql.org/list/pgadmin-support/
>
> pgAdmin comes from EDB also, maybe someone on that list could pass your
> issue on.

I guess this is where EDB installer issues should go:

https://github.com/EnterpriseDB/edb-installers/issues

It seems like there are about 3 different problems associated with the
new Turkish_Türkiye.1254 locale name:

1. EDB's installer apparently has a problem with the encoding of the
name of the locale itself.  Looking at your log file with my pager, it
shows:

The database cluster will be initialized with locale
"Turkish_Trkiye.1254".

I think that means that it had the name of the locale encoded as
"CP437" at some point (where ü is 0x81, apparently[1]), but then
somewhere it was reencoded to the sequence 0xc2 0x81 (shown by my
pager as ), which is nonsense.  The way to get there would be
to believe falsely that the source encoding was Latin1, I guess.

I'm not even sure what encoding it should be giving to initdb (maybe
the ACP of your system?), and in fact it's a bit undefined for
PostgreSQL at least, but that seems to be double-confused.  I suspect
the solution to this might be for  EDB's installer to somehow convert
your selected language to the modern short code format, like "tr-TR".
Those are pure ASCII.  I don't know where it should get the list from.

2.  Some existing database clusters which had been installed with the
name "Turkish_Turkey.1254" became unstartable when the OS upgrade
renamed that locale to "Turkish_Türkiye.1254".  I'm trying to provide
a pathway[2] to fix such systems in core PostgreSQL in the next minor
release.  Everyone affected probably already found another way but at
least next time a country is renamed this might help with the next
point too.

3.  I'd also like to teach initdb to use BCP47 names like "tr-TR"
instead of those names by default (ie if you don't specify a locale
name explicitly), and have proposed that before[3] but it hasn't gone
in due to lack of testing/reviews from Windows users.  It seems like
that doesn't matter much in practice to all the people using the
popular EDB installer, since it apparently takes control of picking
the locale and explicitly passes it in (and screws up the encoding as
we have now learned).

As for your immediate problem, you can also use initdb.exe directly to
set up a cluster, and tell it to use locale tr-TR.  I can't recommend
all the switches you'd need to pass it for best compatibility with the
EDB GUI tools though, but maybe the ones from your log.

[1] https://en.wikipedia.org/wiki/%C3%9C#Computing_codes
[2] 
https://www.postgresql.org/message-id/flat/CA%2BhUKGJTOgnTzu4VD6Am0X6g67atkQHFVk%2BC-w5wkGrGiao-%3DQ%40mail.gmail.com#556557efd6b83cd7a336b62507efe347
[3] 
https://www.postgresql.org/message-id/flat/CA%2BhUKGJ%3DXThErgAQRoqfCy1bKPxXVuF0%3D2zDbB%2BSxDs59pv7Fw%40mail.gmail.com

Re: Windows installation problem at post-install step

[Ertan Küçükoglu]

Thomas Munro , 21 Tem 2024 Paz, 23:27 tarihinde
şunu yazdı:

> I guess this is where EDB installer issues should go:
>
> https://github.com/EnterpriseDB/edb-installers/issues


Thanks. I just added a new issue there.

2.  Some existing database clusters which had been installed with the
> name "Turkish_Turkey.1254" became unstartable when the OS upgrade
> renamed that locale to "Turkish_Türkiye.1254".  I'm trying to provide
> a pathway[2] to fix such systems in core PostgreSQL in the next minor
> release.  Everyone affected probably already found another way but at
> least next time a country is renamed this might help with the next
> point too.
>

I was also hit by that OS update.
There is a Microsoft tool for creating a locale installer
https://www.microsoft.com/en-us/download/details.aspx?id=41158
Using that tool and adding a second locale Turkish_Turkey.1254 (name before
Microsoft update) in the OS can fix your broken PostgreSQL.
I believe most people simply choose this path.
There are also several blogs/articles written in Turkish about the problem.

3.  I'd also like to teach initdb to use BCP47 names like "tr-TR"
> instead of those names by default (ie if you don't specify a locale
> name explicitly), and have proposed that before[3] but it hasn't gone
> in due to lack of testing/reviews from Windows users.  It seems like
> that doesn't matter much in practice to all the people using the
> popular EDB installer, since it apparently takes control of picking
> the locale and explicitly passes it in (and screws up the encoding as
> we have now learned).
>

If I am not mistaken BCP47 names are already used in Linux systems.
Using them would make PostgreSQL use the same locale names across Linux and
Windows systems.
I can help with the testing part. Let me know the details, please.

Thanks & Regards,
Ertan

Re: Windows installation problem at post-install step

[Thomas Munro]

On Mon, Jul 22, 2024 at 11:58 AM Ertan Küçükoglu
 wrote:
> Thomas Munro , 21 Tem 2024 Paz, 23:27 tarihinde şunu 
> yazdı:
>> 2.  Some existing database clusters which had been installed with the
>> name "Turkish_Turkey.1254" became unstartable when the OS upgrade
>> renamed that locale to "Turkish_Türkiye.1254".  I'm trying to provide
>> a pathway[2] to fix such systems in core PostgreSQL in the next minor
>> release.  Everyone affected probably already found another way but at
>> least next time a country is renamed this might help with the next
>> point too.
>
> I was also hit by that OS update.
> There is a Microsoft tool for creating a locale installer
> https://www.microsoft.com/en-us/download/details.aspx?id=41158
> Using that tool and adding a second locale Turkish_Turkey.1254 (name before 
> Microsoft update) in the OS can fix your broken PostgreSQL.
> I believe most people simply choose this path.
> There are also several blogs/articles written in Turkish about the problem.

If that's easy and good enough then maybe I should abandon that
on-the-fly renaming patch and we should just do a little documentation
note...

>> 3.  I'd also like to teach initdb to use BCP47 names like "tr-TR"
>> instead of those names by default (ie if you don't specify a locale
>> name explicitly), and have proposed that before[3] but it hasn't gone
>> in due to lack of testing/reviews from Windows users.  It seems like
>> that doesn't matter much in practice to all the people using the
>> popular EDB installer, since it apparently takes control of picking
>> the locale and explicitly passes it in (and screws up the encoding as
>> we have now learned).
>
> If I am not mistaken BCP47 names are already used in Linux systems.
> Using them would make PostgreSQL use the same locale names across Linux and 
> Windows systems.

Not exactly.  POSIX systems use
[language[_territory][.codeset][@modifier]], but POSIX doesn't say
what any of those components are[1] (are they ISO country codes?
English words?  Hieroglyphs?), so, curiously, those Windows names like
"English_United States.1252" are probably POSIX-conforming.  Every
real POSIX system of course uses ISO language and country codes these
days (though I still recall other names being used years ago), so they
look similar to the simpler kinds of BCP47 tags, which are just
language-country with the same ISO codes but a different separator.
They diverge further once you get into the finer points with more
components.  Incidentally that lack of standardisation is the reason
you can't say that the glibc ".utf8" ending is "wrong", even though it
is obviously stupid :-p (all systems I know accept .UTF-8, 'cause
that's what Ken Thompson, Rob Pike and the Unicode standard called
it).  I suspect that Windows accepts the POSIX style en_US too, but
it's not what the manual tells you to use.

But really we shouldn't have to know or care how locales are named; we
should get the names from the OS in the first place, and then we
should remember them and give them back to the OS at the right times.
The two problems here is that Windows has two kinds, one unstable over
time and with illegal (for us) characters in the name, and one stable;
we need to find all the places where the old unstable ones can get
into our system, and block them off.  I'm aware of two places now: the
EDB installer, and initdb's default for people who run it on the
command line with giving an explicit name.

> I can help with the testing part. Let me know the details, please.

Thanks!  I will rebase that patch, and CC you on the thread.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

pgBackRest for multiple production servers

[KK CHN]

Hi list ,

I am exploring the  PgBackRest tool for production deployment. ( My lab
setup with one   Database server and another Reposerver deployed working
fine as in the official docs)

Query:

What may be the standard practice employed to  backup multiple production
servers to one RepoServer ? ( the pgbackrest configuration on the
RepoServer part )

Is this the  right way to achieve this (Defining multiple stanzas
Server1,  Server  2 ..  Server  N and single  [global] with  repo1, repo2
and repon N  declarations   ?

Please correct me if I am wrong ..

Thank you
Krishane


Please find the proposed   pgbackrest.conf   in the  RepoServer  for
backing up multiple database servers.

/etc/pgbackrest/pgbackrest.conf   on  RepoServer
##
[ Server  _1]
pg1-host=10.20.20.6
pg1-host-user= pgbackUser
pg1-path=/var/lib/pgsql/16/data
. . . . .  . . .  . . . . . . . . . . . . . . . . .
. . . . . . .  .  .  .  .  .  .  .  .  .  .  .  .  .
. . . . . . . . . .  . . . . . .. .. . .. . . . .

[ Server  _N]
pgN-host=10.20.20.N
pgN-host-user= pgbackUser
pgN-path=/var/lib/pgsql/16/data


[global]
repo1-path=/var/lib/ Server_1_Backup
repo1-retention-full=2
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=0oahu5f5dvH7eD4TI1eBEl8Vpn14hWEmgLGuXgpUHo9R2VQKCw6Sm99FnOfHBY
process-max=5
log-level-console=info
log-level-file=debug
start-fast=y
delta=y
repo1-block=y
repo1-bundle=y

repo2-path=/var/lib/ Server_2_Backup
repo2-retention-full=2
repo2-cipher-type=aes-256-cbc
repo2-cipher-pass=0oahu5f5dvH7eD4TI1eBEl8Vpn14hWEmgLGuXgpUHo9R2VQKCw6Sm99FnOfHBY
process-max=5
log-level-console=info
log-level-file=debug
start-fast=y
delta=y
repo2-block=y
repo2-bundle=y

.   .   .   .  . .  .  .   .  .  .  .  .  .  .  .  .  .  . .  .  .  .  .
.  .
.   .   .   .  . .  .  .   .  .  .  .  .  .  .  .  .  .  . .  .  .  .  .
.  .
.   .   .   .  . .  .  .   .  .  .  .  .  .  .  .  .  .  . .  .  .  .  .
.  .

repoN-path=/var/lib Server_N_Backup
repoN-retention-full=2
repoN-cipher-type=aes-256-cbc
repoN-cipher-pass=0oahu5f5dvH7eD4TI1eBEl8Vpn14hWEmgLGuXgpUHo9R2VQKCw6Sm99FnOfHBY
process-max=5
log-level-console=info
log-level-file=debug
start-fast=y
delta=y
repoN-block=y
repoN-bundle=y


[global:archive-push]
compress-level=3
###

Re: Re. Select with where condition times out

[sivapostg...@yahoo.com]

 

On Sunday, 21 July, 2024 at 12:52:22 am IST, Michael Nolan 
 wrote:  
 
 On Thu, Jul 18, 2024 at 4:38 AM sivapostg...@yahoo.com
 wrote:
>
> Hello,
> PG V11
>
> Select count(*) from table1
> Returns 10456432
>
> Select field1, field2 from table1 where field3> '2024-07-18 12:00:00'
> Times out
>
> The above query was working fine for the past 2 years.
>
> Backup was taken a day back.  Need to recover complete data as far as 
> possible.
>
> Any possible way(s) to do this?
>
> BKR Sivaprakash
>

If you do a full backup, does it complete in a normal manner and the usual time?

Have you tried doing a shutdown and restart of the database, or
possibly rebooting the server?

You may need to alter the database server settings to increase the
maximum query time.

Mike Nolan
htf...@gmail.com

1.  Full backup taken without any issue.  Checked it by restoring as another 
database in the same server.  No Issues.
2.  PG Service stopped and re-started.    Re-booted the server also.  Same 
issue.
3.  PG is working with default settings only, that's set during installation 
time.  
When the query was run in the restored database, in the same server machine, 
the query executed in a second.  The same query, in original database, takes 
more than 15 min.  
BKR Sivaprakash
  

Re: Fwd: Regarding tables detach concurrently with run_maintenance_proc()

[Muhammad Imtiaz]

Hi ,

You can consider the pg_pathman extension.



*Muhammad Imtiaz*

*PostgreSQL Technical Support Lead *
*/ Pakistan R&D*
*Mobile: +923345072521*
*Email: imtia...@bitnine.net *

On Fri, Jul 19, 2024 at 7:55 PM Durgamahesh Manne 
wrote:

>
>
> On Fri, Jul 19, 2024 at 7:55 PM Christoph Berg  wrote:
>
>> Re: Durgamahesh Manne
>> > with pg_partman By default proc() does not detach tables concurrently.
>> How
>> > do we implement tables detach concurrently without blocking other
>> sessions
>> > Here queries not using date column to detach tables with
>> > run_maintenance_proc() which is not using concurrently  based on the
>> > retention policy which leads to scan all available child tables hence
>> need
>> > to trigger this proc with concurrently option to avoid blocking other
>> child
>> > tables beyond rentention policy while running statements on them
>>
>> You might have more success by filing pg_partman issues at
>> https://github.com/pgpartman/pg_partman/issues
>>
>> > Do we have any other alternative rather than using pg_partman()?
>>
>> Well you can just run the same commands manually that pg_partman would
>> run.
>>
>> Christoph
>>
>
> Hi
> You might have more success by filing pg_partman issues at
> https://github.com/pgpartman/pg_partman/issues >>> okay
>  My intention is to have any other extension other than pg_partman to
> manage table partitions manually
>
> Regards
> Durga Mahesh
>

Re: Re. Select with where condition times out

[sivapostg...@yahoo.com]

 
On Saturday, 20 July, 2024 at 10:55:30 pm IST, Francisco Olarte 
 wrote:  
 
 Hi:

Please, avoid top posting, specially when replying to long mail with
various points,m it makes it nearly impossible to track what you are
replying to.

OK

On Sat, 20 Jul 2024 at 13:44, sivapostg...@yahoo.com
 wrote:
> Executed
> VACUUM FULL VERBOSE
> followed by
> REINDEX DATABASE dbname;

As it has been already said, vacuum full implies reindex ( it
basically copies old table to a new one, including indexes, swaps
them, deletes old one ).
> It didn't increase the performance, still time out happened.  VACUUM didn't 
> find any dead rows in that particular table.

The no dead rows is the interesting part.
Yes no dead rows.  



> Yes, the actual query and conditions were not given in my first comment.  
> Actually where condition is not on the date field alone and the query with 
> current date is only a sample.

Then they are worthless and harmful. Query time problems is normally
data and statistics dependent and always query dependent.

The query you posted has only two ways to be done, and few ways to be
improved. Suggestions for it will probably be harmful for other
queries.

Actual Query: select source_node_id, create_time from sym_data where table_name 
= 'tx_combined_sales_header' and ((event_type = 'I' and row_data like 
'"F92DD7AA237A45D99CA5741DF73EA3D1"%') or (event_type in ('U', 'D') and pk_data 
like '"F92DD7AA237A45D99CA5741DF73EA3D1"')) and create_time >= '2024-07-18 
01:43:32.981' order by create_time desc


> What I did,
> 1.  Took backup (pg_dump) of the database from the server it's running.  [ 
> Server config. Xeon Silver 4208, Windows Server 2019 Standard ].
> 2.  Restored in another desktop system, installing PG 11 afresh.
> 3.  Performance was excellent.  Within milliseconds I got the result.  
> Application was run from the desktop.
> 4.  Restored the database in the same server, as another database.  Improved 
> performance but doesn't match the performance of the desktop.  Application 
> run from the server itself.

What you did not:
- Show your tables and indexes.
- Show your real queries.
- Tell us what "the application is" ( i.e., "psql", "a java app using
JDBC", ... )

> Now server got two databases with exactly the same data.  Old one takes more 
> than 15 minutes; newer one takes few seconds.  Application run from the 
> server and also from clients.  In both conditions, the result is same.

After what has been happening, I have to ask. Do you mean ONE server
with two databases, or TWO servers with one database each? Also, what
are the especs of the server and the desktops, and the postgres
configuration on each? A misconfigured server can easily send query
time through the roof ( i.e., DB servers want real RAM, if you
configure postgres with too much mem and it swaps you can make a query
really slow )

I thought I'm clear. My bad.
2 computers were involved in total.  One Xeon Server with Windows 2019 Standard 
and other one is Intel i5 based Desktop with Windows 10.
I took backup (pg_dump) from windows server machine.
And restored in the same server as another database.  Now we have 2 databases 
with identical data in Windows Server. The actual query (given above) is taking 
more than 15 min in the original database and takes a second in the restored 
database.
Also I restored the database in Desktop machine also, which takes ms only.All 
PG settings are set at installation, and nothing changed by us. 



> What else I need to do to correct this issue?

No clue.
I have done Vacuum, Re-Index in the original database. No improvement. Anything 
else that I can do to make the original database to perform just like the 
restored database?

> I can easily replace the old database with the backup.  Is that only option?

Ah, one clue. From the info I have in this and previous mails, that is
the only option for me. Having more info someone may have ideas, but
so far the only thing I have concluded is three databases, fast in
server, slow in server and desktop, test only. So my only options are
fast server and slow server. So my solution would be  "use fast
server". As I said, maybe having more data we could suggest "analyze
that table with these parameters", or "make this index" or "rewrite
this condition in this way", but this is impossible to do with the
data you provided.

What else ?

Regards.
Francisco Olarte.