On Thu, Aug 8, 2024 at 6:10 AM Thomas Munro wrote:
> Thanks. The log didn't offer any more clues, and my colleague David R
> has Windows and knows how to work its debugger so we sat down together
> and chased this down (thanks David!).
>
> 1. It is indeed calling abort(), but it's not a PANIC o
On Wednesday, August 7, 2024, dfgpostgres wrote:
>
> (select
> domain_name,
> sum(total_tests) as total_tests,
> sum(tests_completed) as tests_completed,
> sum(tests_passed) as tests_passed,
> sum(tests_failed) as tests_failed,
> (select count(*) from dispatch_tracker wh
pg 15.3 on linux
I don't even know if the title makes sense, I think it's better explained
with an example
This is the table...
dvdb=# \d dispatch_tracker
Table "regr.dispatch_tracker"
Column| Type | Collation | Nullable |
Default
> You could probably do some sampling of the pg_stat_progress_analyze
> view to figure out what's taking the most time.
I did another run, sampling the pg_stat_progress_analyze every 30s.
For the first 4 minutes it was working on the partitioned table.
After that it began analyzing all the parti
Thanks. The log didn't offer any more clues, and my colleague David R
has Windows and knows how to work its debugger so we sat down together
and chased this down (thanks David!).
1. It is indeed calling abort(), but it's not a PANIC or Assert() in
PostgreSQL, it's an assertion inside Windows' ow
On Wed, Aug 7, 2024 at 3:13 AM Ron Johnson wrote:
> On Tue, Aug 6, 2024 at 5:07 PM yudhi s
> wrote:
>
>> Hi All,
>> We are having a use case in which we are having transaction data for
>> multiple customers in one of the Postgres databases(version 15.4) and we
>> are consuming it from multiple s
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 column which will be very fast within seconds as it
>> will jus
On Wed, Aug 7, 2024 at 3:41 AM Daniel Gustafsson wrote:
> > On 6 Aug 2024, at 18:29, Christophe Pettus wrote:
> >> On Aug 6, 2024, at 08:11, bruno vieira da silva
> wrote:
>
> >> the pg doc
> >> mentions a considerable performance penality, how considerable it is?
> >
> > That line is probably
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 column which will be very fast within seconds as it will
> just add it to the data dictionary.
>
> ALTER TABLE tab1 ADD COL
On Wed, Aug 7, 2024 at 4:39 PM Lok P wrote:
> Hello all,
> We have a postgres table which is a range partitions on a timestamp column
> having total size ~3TB holding a total ~5billion rows spanning across ~150
> daily partitions and there are ~140+columns in the table. Also this table
> is a chi
Hello all,
We have a postgres table which is a range partitions on a timestamp column
having total size ~3TB holding a total ~5billion rows spanning across ~150
daily partitions and there are ~140+columns in the table. Also this table
is a child to another partition table. And we have partition cre
On Wed, 7 Aug 2024 at 19:20, Michael Harris wrote:
> I found that running an ANALYZE specifying only those 4 columns only took
> 5 minutes, compared to the 30 minutes for the whole table.
>
> That was a bit of a surprise as I imagined actually reading the table would
> take
> most of the time and
> On 6 Aug 2024, at 18:29, Christophe Pettus wrote:
>> On Aug 6, 2024, at 08:11, bruno vieira da silva wrote:
>> the pg doc
>> mentions a considerable performance penality, how considerable it is?
>
> That line is probably somewhat out of date at this point. We haven't seen a
> significant s
Many thanks David for the comprehensive response.
> I think the complaint was about no autovacuum on the partitioned
> table, not the partitions.
Yes, exactly.
One other piece of information: these tables contain a lot of columns, of which
only 4 are normally used for WHERE clauses or joins. The
14 matches
Mail list logo
