Sv: Support for dates before 4713 BC

På mandag 04. mars 2024 kl. 17:01:46, skrev Koschicek-Krombholz, Bernhard < bernhard.koschicek-krombh...@oeaw.ac.at >: It would be very useful if PostgreSQL would support dates before 4713 BC. Out of curiosity, are there any plans to implement

CTEs and concurrency

Dear, I am currently running a chaos test on a system (essentially starting nodes that process something and randomly knockign them out). It appeared to work fine with regular tests but I am seeing occasional duplicate key value violattions of a uniqueness constraint on one of the complexer

Support for dates before 4713 BC

It would be very useful if PostgreSQL would support dates before 4713 BC. Out of curiosity, are there any plans to implement it in the near future? All the best, Bernhard Koschicek-Krombholz

Re: When manual analyze is needed

On Mon, 4 Mar 2024 at 21:46, Greg Sabino Mullane wrote: > On Mon, Mar 4, 2024 at 12:23 AM veem v wrote: > >> Additionally if a query was working fine but suddenly takes a >> suboptimal plan because of missing stats , do we have any hash value column >> on any performance view associated with

Is partition pruning impacted by data type

Hi, We are designing one application which is currently restricted to one time zone users but has the possibility to go global in future. Some of the transaction tables are going to be daily range partitioned on the transaction_create_date column. But the "date" data type will have no time

Re: When manual analyze is needed

On Mon, Mar 4, 2024 at 12:23 AM veem v wrote: > Additionally if a query was working fine but suddenly takes a > suboptimal plan because of missing stats , do we have any hash value column > on any performance view associated with the queryid which we can refer to > see past vs current plans

Re: postgres_fdw aggregate pushdown for group by with expressions

=?utf-8?Q?Micha=C5=82_K=C5=82eczek?= writes: > Does that mean that *any* expression containing text constants is not going > to be pushed down?? > That would be a really serious issues I’d say. If it contains text constants and not text variables, possibly so. Keep in mind though that this rule

Re: Inconsistent results in timestamp/interval comparison

On Mon, 4 Mar 2024 at 14:06, wrote: > Am 04.03.2024 13:45 schrieb Francisco Olarte: > > Intervals are composed of months, days and seconds, as not every month > > has 30 days and not every day has 86400 seconds, so to compare them > > you have to normalize them somehow, which can lead to bizarre

Re: Inconsistent results in timestamp/interval comparison

Am 04.03.2024 13:45 schrieb Francisco Olarte: Intervals are composed of months, days and seconds, as not every month has 30 days and not every day has 86400 seconds, so to compare them you have to normalize them somehow, which can lead to bizarre results. Ah, I see, thanks for the explanation.

Re: Inconsistent results in timestamp/interval comparison

On Mon, 4 Mar 2024 at 13:46, Francisco Olarte wrote: > On Mon, 4 Mar 2024 at 13:10, wrote: > > According to the documentation, Table 9.31, IMHO both comparisons should > > produce the same results, as > > > timestamp - timestamp → interval > > timestamp + interval → timestamp > Your problem may

Re: Inconsistent results in timestamp/interval comparison

On Mon, 4 Mar 2024 at 13:10, wrote: > According to the documentation, Table 9.31, IMHO both comparisons should > produce the same results, as > timestamp - timestamp → interval > timestamp + interval → timestamp Your problem may be due to interval comparison. Intervals are composed of months,

Re: postgres_fdw aggregate pushdown for group by with expressions

Hi All, > On 3 Mar 2024, at 10:34, Michał Kłeczek wrote: > > Hi, > > I have the following foreign table: > > CREATE FOREIGN TABLE t1 ( > grouping_column text, > date_column date, > whatever_data int > ); > > The query is: > > SELECT > sum(whatever_data) > FROM > t1 > GROUP BY >

Inconsistent results in timestamp/interval comparison

Hi all, I run the “official” deb package postgresql-16 v. 16.2-1.pgdg120+2 on a Debian Bookworm system, and observed a confusing behavior in a calculation with time stamps and intervals. To reproduce, consider the following trivial example: create table testtab (t1 timestamp without time

Re: When manual analyze is needed

On Mon, 2024-03-04 at 10:16 +0530, veem v wrote: > So the partitioned table stats is nothing but the rolledover stats of all the > partitions. > As you mentioned, autoanalyze only works for child partitions but not the > partition tables, > so does it mean we have to schedule some jobs