On 2019-Jul-10, Steve Atkins wrote:
> > On Jul 10, 2019, at 7:38 PM, Bruce Momjian wrote:
> >> I'd like to DRY them up so there aren't two lists which confuses
> >> newcomers. Any objections? If not I'll probably make one of those
> >> pages into GUI's and one into "non GUI's" or something lik
On 2019-Jul-26, Arya F wrote:
> I think I can modify my application to do a batch update. Right now the
> server has an HDD and it really can't handle a lot of updates and inserts
> per second. Would changing to a regular SSD be able to easily do 3000
> updates per second?
That's a pretty hard qu
On Fri, Jul 26, 2019 at 3:24 PM Tom Lane wrote:
> [ please don't top-post ]
>
> Arya F writes:
> > On Fri, Jul 26, 2019 at 3:03 PM Ron wrote:
> >> On 7/26/19 2:56 PM, Arya F wrote:
> >>> Would it be possible to achieve 12,000,000 writes/updates on a single
> >>> server? If so what kind of hardw
[ please don't top-post ]
Arya F writes:
> On Fri, Jul 26, 2019 at 3:03 PM Ron wrote:
>> On 7/26/19 2:56 PM, Arya F wrote:
>>> Would it be possible to achieve 12,000,000 writes/updates on a single
>>> server? If so what kind of hardware should I be looking for?
>> That's only 3,333 modification
As most about 2000 characters.
On Fri, Jul 26, 2019 at 3:03 PM Ron wrote:
> On 7/26/19 2:56 PM, Arya F wrote:
> > Would it be possible to achieve 12,000,000 writes/updates on a single
> > server? If so what kind of hardware should I be looking for?
>
> That's only 3,333 modifications/second. Ho
On 7/26/19 2:56 PM, Arya F wrote:
Would it be possible to achieve 12,000,000 writes/updates on a single
server? If so what kind of hardware should I be looking for?
That's only 3,333 modifications/second. How big are your records?
--
Angular momentum makes the world go 'round.
Would it be possible to achieve 12,000,000 writes/updates on a single
server? If so what kind of hardware should I be looking for?
Correct, seems to be something wrong on system tables. Maybe our script is
running something is already there, we will check.
select * from pg_stat_sys_tables where schemaname = 'pg_catalog'
relname n_live_tup n_dead_tup
pg_attrdef 3699 1095
pg_index
pg_stat_all_tables
count count
37158 807
pg_stat_sys_tables
count count
16609 223
pg_stat_user_tables
count count
20549 584
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
On Fri, Jul 26, 2019 at 1:15 PM PegoraroF10 wrote:
>
> select count(*), count(*) filter (where last_autovacuum is not null) from
> pg_stat_all_tables
> count count
> 36605 1178
>
What are the results of the same query against pg_stat_sys_tables and
pg_stat_user_tables? That's would help under
On 7/26/19 4:15 AM, PegoraroF10 wrote:
select count(*), count(*) filter (where last_autovacuum is not null) from
pg_stat_all_tables
count count
36605 1178
But what tables should I see if vacuum ran on it ?
I would recommend reading this:
https://www.postgresql.org/docs/11/routine-vacuumin
On 25/7/19 5:24 AM, Souvik Bhattacherjee wrote:
> I got this thing running and hopefully works as expected. The txns are
> stored in insert_txn1.sql, insert_txn2.sql, ...
> Please let me know if you find any issues with this.
> Script is attached.
>
Even if you're using the ancient Bash version 3 (
select count(*), count(*) filter (where last_autovacuum is not null) from
pg_stat_all_tables
count count
36605 1178
But what tables should I see if vacuum ran on it ?
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
Nope, that schema and all its entire structure did not exist.
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
Running that sql:
namesetting
autovacuum on
autovacuum_analyze_scale_factor 0.1
autovacuum_analyze_threshold50
autovacuum_freeze_max_age 2
autovacuum_max_workers 3
autovacuum_multixact_freeze_max_age 4
autovacuum_naptime 60
autovacuum_vacuum_cost_delay
PegoraroF10 schrieb am 26.07.2019 um 00:16:
> statement: create or replace function valoresdfe... 0 mins 1.135 secs
> statement: create or replace function dadosorigem...0 mins 0.055 secs
> statement: CREATE OR REPLACE FUNCTION SONU... 0 mins 0.013 secs
> statement: create or repl
Julien,
Because it's production code generated by our ORM for this command:
`Patient.find_by(last_name: 'champier')`.
Of course this was not intended by the developer that though the last_name
was unique.
On Fri, Jul 26, 2019 at 10:10 AM Julien Rouhaud wrote:
> On Fri, Jul 26, 2019 at 9:53 AM
On Fri, Jul 26, 2019 at 9:53 AM Cyril Champier
wrote:
>
> Adrian:
>
>> Are you really looking for a pseudo-random name?
>
>
> No, the code I pasted was an existing production bug: the last_name should
> have been unique, so the selected patient would always be the same.
> This should have been de
On Fri, Jul 26, 2019 at 1:01 AM PegoraroF10 wrote:
>
> Nope, no one message near those statements.
> I haven´t changed anything on Postgres.conf related with autovacuum.
>
Please take a look and post results of the following query:
select name, setting from pg_settings where name like 'autovacuu
Adrian:
Are you really looking for a pseudo-random name?
No, the code I pasted was an existing production bug: the last_name should
have been unique, so the selected patient would always be the same.
This should have been detected in tests, but since the order was "almost
always the same", our t
20 matches
Mail list logo
