Re: Qualifying use of separate TABLESPACES (performance/functionality)

> On Jul 16, 2024, at 21:45, imndl...@gmx.com wrote: > Or, does Postgres expect to be able to access any media however it wants > (i.e., R/w), regardless of the expected access patterns of the data stored > there? Well, yes and no. PostgreSQL will not respond well to having media that is liter

Qualifying use of separate TABLESPACES (performance/functionality)

Hi, I'm designing an appliance (think: 24/7/365/decades) in which Postgres will act as a "skin" on the sole persistent store. I.e., there is no "filesystem" visible to clients; *all* persistent (and temporary/shared) data is presented through Postgres. There are three different types of data ma

Re: Code does Not Read in FY 2025 Data

On Tue, Jul 16, 2024 at 7:59 AM Anthony Apollis wrote: > I am using Postgres and SQL Server. > Can you test the data pls. > >> >> Well, this is a PostgreSQL community so you should target it with your communications. If you want someone to actually test things here you probably will need to prod

Re: Code does Not Read in FY 2025 Data

On 7/16/24 08:57, Anthony Apollis wrote: That very same code is picking up all the data in the Original Table. Which only contains past data. It would. select CURRENT_DATE; current_date -- 2024-07-16 "Date" < CURRENT_DATE would return data < 2024-07-16. You want data that has

Re: Code does Not Read in FY 2025 Data

That very same code is picking up all the data in the Original Table. Which only contains past data. On Tue, 16 Jul 2024 at 17:39, Adrian Klaver wrote: > On 7/16/24 08:28, Anthony Apollis wrote: > > Only data up until 2024 is picked up in Revised table, whic contains > > 2025 data. THe Maxdate c

Re: Code does Not Read in FY 2025 Data

On 7/16/24 08:28, Anthony Apollis wrote: Only data up until 2024 is picked up in Revised table, whic contains 2025 data. THe Maxdate calculation seems to be the problem. This: 'Only data up until 2024 is picked up in Revised table, whic contains 2025 data. .." is consistent with: MaxDate A

Re: Code does Not Read in FY 2025 Data

The Calendar Tables should adhere to this business rule/calendar. Original Table seem to be correct. Reporting Month FY22 FY23 FY24 FY25 FY26 FY27 Period End Calendar Days Period End Calendar Days Period End Calendar Days Period End Calendar Days Period End Calendar Days Period End Calendar Days P1

Re: Semantic cache capability for Postgresql db

Hi Pradeep pgprewarm Extension is available for Postgres https://www.postgresql.org/docs/current/pgprewarm.html On Tue, Jul 16, 2024 at 7:05 PM pradeep t wrote: > Hi, > > Shall I use the Postgresql database for a* semantic cache *like the Redis > semantic cache? > Are we currently supporting

Re: Code does Not Read in FY 2025 Data

On 7/16/24 08:26, Anthony Apollis wrote: Again reply to list also Ccing list I included a bigger data set. This code only pics up data up until 2024 in new table which has data for 2025. Something with the Maxdate calculation is wrong. -- Step 1: Define the Fiscal Calendar WITH FiscalCalendar

Re: Code does Not Read in FY 2025 Data

On 7/16/24 08:15, Anthony Apollis wrote: Reply to list also Ccing list i did attached the sample data. Yes I know and the data for 2025 will fail because they are like this: Date FY Period Quarter Day Month YearLoaddate 2025-01-10 00:00:00.000 NULLNULLNULL10 1

Re: Code does Not Read in FY 2025 Data

On 7/16/24 07:59, Anthony Apollis wrote: I am using Postgres and SQL Server. Does the query 'fail' on both platforms? Can you test the data pls. Don't know what I am supposed to see? You will need to provide an explanation of what you want the query to return vs what is currently being re

Re: Code does Not Read in FY 2025 Data

On 16/07/2024 15:59, Anthony Apollis wrote: I am using Postgres and SQL Server. Can you test the data pls. Adrian has already pointed out a possible cause of the issue you are seeing - you should test further based on this. Ray. -- Raymond O'Donnell // Galway // Ireland r...@rodonnell.ie

Re: Code does Not Read in FY 2025 Data

I am using Postgres and SQL Server. Can you test the data pls. On Tue, 16 Jul 2024 at 16:45, Adrian Klaver wrote: > On 7/16/24 05:53, Anthony Apollis wrote: > > 1. The problem is the code below reads only data up until 2024, > > although the table has been updated with latest data that cont

Re: Code does Not Read in FY 2025 Data

On 7/16/24 05:53, Anthony Apollis wrote: 1. The problem is the code below reads only data up until 2024, although the table has been updated with latest data that contains 2025, for some odd reason it is not pulling in or showing data when filtering for 2025 or even 2024 and later, w

Semantic cache capability for Postgresql db

Hi, Shall I use the Postgresql database for a* semantic cache *like the Redis semantic cache? Are we currently supporting such usage? -- Thanks and regards Pradeep.T

Code does Not Read in FY 2025 Data

1. The problem is the code below reads only data up until 2024, although the table has been updated with latest data that contains 2025, for some odd reason it is not pulling in or showing data when filtering for 2025 or even 2024 and later, which should contain all the latest data.

RE: Monitoring DB size

Thanks for the suggestion. I think this will not help us to differentiate between live tuples, dead tuples and free space. Best regards, Manuel From: Torsten Förtsch Sent: 15 July 2024 18:59 To: Shenavai, Manuel Cc: pgsql-general@lists.postgresql.org Subject: Re: Monitoring DB size Slightly d

RE: Monitoring DB size

Hi Muhammad, thanks for the suggestions. Going with pg_stat_user_tables view, we would also need to know the size of the tuple or at least an estimate. Do we know the size of a tuple? Is there a maximum for the tupe size? Best regards, Manuel From: Muhammad Imtiaz Sent: 15 July 2024 17:26 To: