On Thu, Aug 8, 2024 at 4:46 PM Greg Sabino Mullane
wrote:
> _MM_DD is already setup for sorting, so just do:
>
> SELECT table_name FROM information_schema.tables WHERE table_name ~
> 'table_part_p' ORDER BY 1 DESC;
>
> If you need to grab the numbers:
>
> SELECT substring('table_part_p2022_03
> On Aug 8, 2024, at 21:15, Ron Johnson wrote:
>
> "I see a lock, so let's cause another one!" That's crazy.
It's more "Oh, look, I need a connection to service this web request, but my
pool is empty, so I'll just fire up a new connection to the server," lather,
rinse, repeat. Pretty comm
On Thu, Aug 8, 2024 at 10:12 AM Christophe Pettus wrote:
>
>
> > On Aug 7, 2024, at 10:34, Costa Alexoglou wrote:
> >
> > Hey folks,
> >
> > I noticed something weird, and not sure if this is the expected
> behaviour or not in PostgreSQL.
> >
> > So I am running Benchbase (a benchmark framework)
On Fri, 9 Aug 2024 at 02:12, Christophe Pettus wrote:
> VACUUM FULL takes an exclusive lock on the table that it is operating on.
> It's possible that a connection becomes blocked on that exclusive lock
> waiting for the VACUUM FULL to finish, the application sees the connection
> stopped and
_MM_DD is already setup for sorting, so just do:
SELECT table_name FROM information_schema.tables WHERE table_name ~
'table_part_p' ORDER BY 1 DESC;
If you need to grab the numbers:
SELECT substring('table_part_p2022_03_04' from '([\d_]+)$');
Cheers,
Greg
On Thu, Aug 8, 2024 at 2:39 PM Lok P wrote:
> Can anybody suggest any other possible way here.
>
Sure - how about not changing the column type at all?
> one of the columns from varchar(20) to varchar(2)
ALTER TABLE foobar ADD CONSTRAINT twocharplease CHECK (length(mycol) <= 2)
NOT VALID;
> on
Hi ,
We are using postgres version 15.4. We have a range partition table and the
partition naming convention is generated by pg_partman and is something
like "table_name>_p_MM_DD".
We have a requirement of extracting specific partitions ordered by the date
criteria and also do some operations
On 8/8/24 11:07, Anthony Apollis wrote:
The same code bring in values for FY24, 23 etc. Dont understand why
FY25's values are 0.
Because something changed. You will need to go through the process step
by step and verify that the code is current with what is in the FY25 data.
--
Adrian Klaver
> On 8 Aug 2024, at 20:38, Lok P wrote:
>
> Thank you so much.
>
> Can anybody suggest any other possible way here. As, we also need to have the
> existing values be updated to the new column value here using update command
> (even if it will update one partition at a time). And as I see we
> On 8 Aug 2024, at 20:07, Anthony Apollis wrote:
>
> The same code bring in values for FY24, 23 etc. Dont understand why FY25's
> values are 0.
If you use the same code for FY24, then either there’s some filter being
applied somewhere that excludes FY25 (and probably beyond), or something
On Thu, Aug 8, 2024 at 1:06 AM sud wrote:
>
>
> On Wed, Aug 7, 2024 at 5:00 PM Lok P wrote:
>
>>
>>
>> On Wed, Aug 7, 2024 at 4:51 PM sud wrote:
>>
>>>
>>>
>>> Others may correct but i think, If you don't have the FK defined on
>>> these columns you can do below.
>>>
>>>
>>> --Alter table add c
The same code bring in values for FY24, 23 etc. Dont understand why FY25's
values are 0.
On Thu, 8 Aug 2024 at 18:56, Adrian Klaver
wrote:
> On 8/8/24 09:35, Anthony Apollis wrote:
> > I need your assistance with an ETL process that runs every six months.
> > Currently, we are in Calendar Year/F
Hi
čt 8. 8. 2024 v 19:16 odesílatel James Creasy napsal:
> Hi all,
>
> We've spent about 12 hours trying to set up a working debugger for psql
> functions without success, trying both PGAdmin 4 v8.3 and DBeaver.
>
> The online searches turn up multiple instructions for Postgres 12 or
> older, ho
Hi all,
We've spent about 12 hours trying to set up a working debugger for psql
functions without success, trying both PGAdmin 4 v8.3 and DBeaver.
The online searches turn up multiple instructions for Postgres 12 or older,
however we are using 16. Our extensions include PostGIS and supporting
ext
On 8/8/24 09:35, Anthony Apollis wrote:
I need your assistance with an ETL process that runs every six months.
Currently, we are in Calendar Year/FY 2025, which started in July 2024.
The issue is with the "Condition Amount" for FY 2025. Data comes through
correctly until the "Insert Data Into
> On Aug 7, 2024, at 10:34, Costa Alexoglou wrote:
>
> Hey folks,
>
> I noticed something weird, and not sure if this is the expected behaviour or
> not in PostgreSQL.
>
> So I am running Benchbase (a benchmark framework) with 50 terminals (50
> concurrent connections).
> There are 2-3 add
On Thu, 8 Aug 2024 at 11:18, Costa Alexoglou wrote:
...
> So I am running Benchbase (a benchmark framework) with 50 terminals (50
> concurrent connections).
> There are 2-3 additional connections, one for a postgres-exporter container
> for example.
...
> So far so good, and with a `max_connecti
On Thu, Aug 8, 2024 at 5:18 AM Costa Alexoglou wrote:
> Hey folks,
>
> I noticed something weird, and not sure if this is the expected behaviour
> or not in PostgreSQL.
>
> So I am running Benchbase (a benchmark framework) with 50 terminals (50
> concurrent connections).
> There are 2-3 additiona
Hey folks,
I noticed something weird, and not sure if this is the expected behaviour
or not in PostgreSQL.
So I am running Benchbase (a benchmark framework) with 50 terminals (50
concurrent connections).
There are 2-3 additional connections, one for a postgres-exporter container
for example.
So
19 matches
Mail list logo
