I have taken a look at this discussion, at the code and I am confused how we
choose tuple table slot (TTS) type in PG. May be you can clarify this topic or
me.
1. Brief intro. There are four types of TTS. Plan tree «leaves»:
- buffer heap (produced by index and table scans, has system columns
TTS for the tuples constructed from the fixed-sized columns when get a Unique node in the plan.commit 148642d81f046b7d72b3a40182c165e42a8ab6d7
Author: Denis Smirnov
Date: Thu Aug 31 08:51:14 2023 +0700
Change tuple table slot for Unique node to "virtual"
The Unique node us
It looks like my patch was not analyzed by the hackers mailing list due to
incorrect mime type, so I duplicate it here.
commit 2852a3f2fab8e723f208d81c1ad1eb6a6a377b09
Author: Denis Smirnov
Date: Thu Aug 31 08:51:14 2023 +0700
Change tuple table slot for Unique node to "vi
g like miscadmin.h
XXX_INTERRUPTS() macros). So it becomes an extension developer's responsibility
to properly handle this flag in the bgworker’s code. This approach breaks
backward compatibility.
May be I've missed a good solution, do you see any?
Best regards,
Denis Smirnov | Developer
s...@arenad
m as we initialize bgworkers right before ServerLoop(). So we can face
malloc() deadlock on postmaster startup (before ServerLoop() started). Maybe we
should simply use write() and exit() instead of ereport() for bgworker_die()?
Best regards,
Denis Smirnov | Developer
s...@arenadata.io
Arenadata
ostmaster, startup, walsender,
postgres
I suspect there are lots of potential ways to lock on malloc() inside any of
this handlers. An interesting question is why there are still no evidence of
such locks?
Best regards,
Denis Smirnov | Developer
s...@arenadata.io
Arenadata | Godovikova 9-17, Moscow 129085 Russia
52, Andrey Borodin написал(а):
>
>
>
>> 25 авг. 2021 г., в 19:22, Denis Smirnov написал(а):
>>
>> I am going to refactor Greenplum backtraces for error messages and want to
>> make it more compatible with PostgreSQL code. Backtraces in PostgreSQL were
>&g
with this fact - both backtrace functions are async-unsafe:
backtrace_symbols() - always, backtrace() - only for the first call due to
dlopen. I wonder why does PostgreSQL use async-unsafe functions in signal
handlers?
Best regards,
Denis Smirnov | Developer
s...@arenadata.io
Arenadata | Godovikova 9
structions. You can check yourself an attached example below.
simplified_compare_rows.c
Description: Binary data
Best regards,
Denis Smirnov | Developer
s...@arenadata.io
Arenadata | Godovikova 9-17, Moscow 129085 Russia
reservoir was changed.
From a5104b15683524a375aab1beb9615f690de31882 Mon Sep 17 00:00:00 2001
From: Denis Smirnov
Date: Sat, 5 Dec 2020 23:25:29 +1000
Subject: [PATCH v2] Refactor AM analyze (acqiure rows method)
Analyze AM functions were implemented for fix sized block AM (heap
influence). Other
n scan relise
only on relation information during initialization). And as a result we can’t
benefit from column AMs during «analyze t(col)» and consume data only from
target columns. This parameters were added to solve this problem.
Best regards,
Denis Smirnov | Developer
s...@arenadata.io
Are
tests were very simple and they should
not be treated as reliable).
From e33b9c99a6fdac54df40aa0c14eb43b6b1f3709d Mon Sep 17 00:00:00 2001
From: Denis Smirnov
Date: Wed, 16 Dec 2020 22:02:49 +1000
Subject: [PATCH] Rebase patch-27 to actual master and fix strcpy
1. Patch-27 had conflicts
Andrey, thanks for your feedback!
I agree that AMs with fix sized blocks can have much alike code in
acquire_sample_rows() (though it is not a rule). But there are several points
about current master sampling.
* It is not perfect - AM developers may want to improve it with other sampling
lgorithms like A-Chao or
> logical blocks to follow S-Knuth (and have a problem with
> RelationGetNumberOfBlocks() estimating a physical number of blocks). Another
> problem with columns - they are not passed to analyze begin scan and can’t
> benefit from column storage at ANALYZE TABLE (COL)
14 matches
Mail list logo
