Re: How to handle "could not find function xml_is_well_formed" when restoring database in Version 17

2024-10-01 Thread Tom Lane
George Weaver writes: > I am testing upgrading from Version 13 to Version 17.  I am getting the > following error when trying to restore a database in Version 17 (the > database was backed up from Version 13 using the Version 17 pg_dump): > pg_Restore: error: could not execute query: ERROR:

How to handle "could not find function xml_is_well_formed" when restoring database in Version 17

2024-10-01 Thread George Weaver
Good afternoon, I am testing upgrading from Version 13 to Version 17.  I am getting the following error when trying to restore a database in Version 17 (the database was backed up from Version 13 using the Version 17 pg_dump): pg_Restore: error: could not execute query: ERROR:  could not f

Re: How to handle "could not find function xml_is_well_formed" when restoring database in Version 17

2024-10-01 Thread Christoph Moench-Tegeder
## George Weaver (gwea...@shaw.ca): > I am testing upgrading from Version 13 to Version 17.  I am getting > the following error when trying to restore a database in Version 17 > (the database was backed up from Version 13 using the Version 17 > pg_dump): > >pg_Restore: error: could not execut

Reading execution plan - first row time vs last row time

2024-10-01 Thread Pecsök Ján
Dear community, We see significant difference in explain analyze Actual time in the first line of execution plan and Execution time in the last line of execution plan. What can be the reason? For example, first line of execution plan: Gather (cost=1038.49..257627100.42 rows=794326 width=10

Re: Help with query optimizer

2024-10-01 Thread Laurenz Albe
On Tue, 2024-10-01 at 09:36 +0100, David Mullineux wrote: > > On Tue, 1 Oct 2024, 08:53 Siraj G, wrote: > > Can you please help with the attached query as it is taking time to > > execute. The execution plan for the same is below: > > > > [EXPLAIN (ANALYZE, BUFFERS) output] > > Its usually helpful

Re: Question on session timeout

2024-10-01 Thread Greg Sabino Mullane
On Tue, Oct 1, 2024 at 1:57 AM sud wrote: > *Where are you getting the ~2000 count from?* > Seeing this in the "performance insights" dashboard and also its matching > when I query the count of sessions from pg_stat_activity. > So I'm guessing this is perhaps RDS or Aurora? Stating that up fron

Re: Reading execution plan - first row time vs last row time

2024-10-01 Thread Tom Lane
=?iso-8859-2?Q?Pecs=F6k_J=E1n?= writes: > We see significant difference in explain analyze Actual time in the first > line of execution plan and Execution time in the last line of execution plan. > What can be the reason? The time reported for the top query node is just the time taken to comput

Re: Suggestion for memory parameters

2024-10-01 Thread Greg Sabino Mullane
On Tue, Oct 1, 2024 at 2:52 AM yudhi s wrote: > When I execute the query with explain (analyze, buffers),I see the section > below in the plan having "sort method" information in three places > each showing ~75MB size, which if combined is coming <250MB. So , does that > mean it's enough to set t

Re: Reading execution plan - first row time vs last row time

2024-10-01 Thread Greg Sabino Mullane
On Tue, Oct 1, 2024 at 9:53 AM Pecsök Ján wrote: > We see significant difference in explain analyze Actual time in the first > line of execution plan and Execution time in the last line of execution > plan. What can be the reason? > > > > For example, first line of execution plan: > > Gather (co

Re: Reading execution plan - first row time vs last row time

2024-10-01 Thread Adrian Klaver
On 10/1/24 06:53, Pecsök Ján wrote: Dear community, We see significant difference in explain analyze Actual time in the first line of execution plan and Execution time in the last line of execution plan. What can be the reason? For example, first line of execution plan: Gather  (cost=1038.4

Re: Help with query optimizer

2024-10-01 Thread David Mullineux
Hi, Its usually helpful to give some details on what 'slow' means and then define what 'fast enough ' means. Just so we know when to stop optimizing. You should also help by giving the DDL of those.tables and any indexes they have etc.. The plan shows me that there are expensive seq scans on 2 tabl

Re: Question on session timeout

2024-10-01 Thread Adrian Klaver
On 9/30/24 22:57, sud wrote: On Tue, Oct 1, 2024 at 4:10 AM Adrian Klaver > wrote: /Where are you getting the ~2000  count from?/ Seeing this in the "performance insights" dashboard and also its matching when I query the count of sessions from pg_stat_activ