Re: Why are commits consuming most of the database time?

your help. -Tim On Tue, Apr 4, 2023 at 10:55 AM Tim Slechta wrote: > > > On Tue, Apr 4, 2023 at 9:57 AM Tom Lane wrote: > >> Tim Slechta writes: >> > The test data below is from a non-virtualized (client system and >> database >> > server) Postgres 14

Why are commits consuming most of the database time?

is a good approach to identifying what is happening within the commit processing?* *Are there any known bugs in this area?* Any other thoughts would be greatly appreciated. Thank you. -Tim LineFreq Cum.tMax.t Avg.t Rows Err. Statement 1 2268 *301.908

time sorted UUIDs

. ... Any other general comments about time sorted UUIDs would be welcome. Thanks, Tim Jones

Re: Views don't seem to use indexes?

Tom, David, Thank you for the time and information. I lost my system this morning, so I need to re-establish a system and do some additional homework. Thanks again. -Tim BTW: here is the definition of the pworkspaceobject table. tc=# \d+ pworkspaceobject Table

Views don't seem to use indexes?

Why does the planner not use an index when a view is involved? 1) A description of what you are trying to achieve and what results you expect. Why don't plans use indexes when views are involved? A similar query on the underlying table leverages the appropriate index. == Point 1. The following q

Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle

Jeff Holt is probably pretty embarrassed there's some blowhard making a scene using his name in a casual mailing list thread. On Tue, Oct 5, 2021 at 5:28 PM Mladen Gogala wrote: > Comments in-line > > On 10/5/21 16:24, Peter Geoghegan wrote: > > On Fri, Oct 1, 2021 at 1:06 PM Jeff Holt wrote: >

Re: Performance for initial copy when using pg_logical to upgrade Postgres

I'm currently doing this with a 2.2 TB database. Best way IMO is to (UPDATE pg_index SET indisready = false ... ) for non PK indexes for the largest tables. Then just set it back to indisready = true after its done and run a REINDEX CONCURRENTLY on the indexes that were disabled. Got about a tran

Re: Legal disclaimers on emails to this group

message I consider that message to be my property and I will copy, share and deceminate as I see fit. I will provide attribution when appropriate and I willl endeavour to comply with all reasonable requests. However, I reject all threats or implied threats of legal action arising from an error or mistake on your part. It is your responsibility to manage your communications appropriately, not mine. -- Tim Cross

Re: Performance of INSERT into temporary tables using psqlODBC driver

padusuma writes: > Hello Tim, > >>How are you gathering metrics to determine if performance has improved >>or not? > I am measuring the response times through timer for the execution of SQL > statements through psqlODBC driver. The response times for INSERT INTO >

Re: Performance of INSERT into temporary tables using psqlODBC driver

padusuma writes: > Hello Tim, > > I have tried the suggestions provided to the best of my knowledge, but I did > not see any improvement in the INSERT performance for temporary tables. The > Linux host on which PostgreSQL database is installed has 32 GB RAM. > Following are

Re: Performance of INSERT into temporary tables using psqlODBC driver

depend on what the memory and cpu profile of the system is. More memory, less use of temp files, faster system, so spend a bit of time to make sure your system is configured to squeeze as much out of that RAM as you can! -- Tim Cross

Re: Performance of INSERT into temporary tables using psqlODBC driver

mbers (millions) of rows into a postgres database from a Javascript application and found using the COPY command was much, much faster than doing regular inserts (even with multi-insert commit). If you can do this using the driver you are using, that will give you the largest performance boost. -- Tim Cross