> On Feb 10, 2024, at 20:15, Tomas Vondra wrote:
>
> On 2/8/24 14:27, wenhui qiu wrote:
>> Hi Heikki Linnakangas
>>I think the larger shared buffer higher the probability of multiple
>> backend processes accessing the same bucket slot BufMappingLock
>> simultaneously, （
Hi,
I was reminded of the patchset I had posted in this thread by
https://postgr.es/m/679d5455cbbb0af667ccb753da51a475bae1eaed.camel%40cybertec.at
On 2020-07-31 13:35:43 -0400, Robert Haas wrote:
> On Fri, Jul 31, 2020 at 1:00 PM Andres Freund wrote:
> > > Perhaps we could add a comment about
On Sun, Feb 18, 2024 at 2:49 AM Tomas Vondra
wrote:
>
> An alternative approach would be modifying pg_typeof() to optionally
> determine the base type, depending on a new argument which would default
> to "false" (i.e. the current behavior).
>
> So you'd do
>
> SELECT pg_typeof(x);
>
> or
>
>
Hi James,
Thanks for the updated patch. I don't have a clear opinion on the
feature and whether this is the way to implement it, but I have two
simple questions.
1) Do we really need to modify RecordTransactionCommitPrepared and
XactLogCommitRecord to return the LSN of the commit record? Can't
Hi,
On 2024-02-17 23:40:51 +0100, Matthias van de Meent wrote:
> > 5. Re-map the shared_buffers when needed.
> >
> > Between transactions, a backend should not hold any buffer pins. When
> > there are no pins, you can munmap() the shared_buffers and mmap() it at
> > a different address.
I hadn't
Tomas Vondra writes:
> On 2/17/24 20:20, Tom Lane wrote:
>> I don't have an immediate proposal for exactly what to call such a
>> function, but naming it by analogy to pg_typeof would be questionable.
> Are you objecting to the pg_basetypeof() name, or just to it accepting
> "any" argument? I
Hi,
Please don't too-post on this list. The custom is to bottom-post or
reply inline, and it's much easier to follow such replies.
On 12/23/23 23:45, Przemysław Sztoch wrote:
> date_bin has big problem with DST.
> In example, if you put origin in winter zone, then generated bin will be
>
On 2/17/24 20:20, Tom Lane wrote:
> Tomas Vondra writes:
>> On 2/17/24 01:57, jian he wrote:
>>> On Sat, Feb 17, 2024 at 2:16 AM Tomas Vondra
>>> wrote:
1) We already have pg_typeof() function, so maybe we should use a
similar naming convention pg_basetypeof()?
>
>>> I am ok with
On 1/18/24 01:25, Cedric Villemain wrote:
> Hi,
>
> I was testing the index prefetch and streamIO patches and I added
> cachestat() syscall to get a better view of the prefetching.
>
> It's a new linux syscall, it requires 6.5, it provides numerous
> interesting information from the VM for the
On Fri, 16 Feb 2024 at 21:36, Paul Jungwirth
wrote:
>
> On 1/15/24 02:37, Peter Eisentraut wrote:
> > In this updated patch set, I have also added the treatment of the
> > Constraint type. (I also noted
> > that the manual read/write functions for the Constraint type are
> > out-of-sync again,
On Fri, 16 Feb 2024 at 21:24, Heikki Linnakangas wrote:
>
> On 16/02/2024 06:28, Robert Haas wrote:
> > 3. Reserve lots of address space and then only use some of it. I hear
> > rumors that some forks of PG have implemented something like this. The
> > idea is that you convince the OS to give you
Hi David,
Do you plan to work continue working on this patch? I did take a look,
and on the whole it looks reasonable - it modifies the right places etc.
I think there are two things that may need an improvement:
1) Storing variable-length data in ParallelBitmapHeapState
I agree with Robert
On Thu, 1 Feb 2024, 17:06 Michail Nikolaev, wrote:
>
> > > > I just realised there is one issue with this design: We can't cheaply
> > > > reset the snapshot during the second table scan:
> > > > It is critically important that the second scan of R/CIC uses an index
> > > > contents summary (made
Hi,
On 2024-02-17 17:48:23 +0100, Laurenz Albe wrote:
> - Patch 0001 speeds up pq_begintypsend with a custom macro.
> That brought the binary copy down to 3.7 seconds, which is a
> speed gain of 15%.
Nice win, but I think we can do a bit better than this. Certainly it shouldn't
be a macro,
Hi,
On 2024-02-16 20:10:48 -0500, Tom Lane wrote:
> Tomas Vondra writes:
> > On 2/17/24 00:14, Tom Lane wrote:
> >> The conclusion was that the specific invalid values didn't matter as
> >> much on the other platforms as they do with glibc. But right now you
> >> have a fifty-fifty chance that
Tomas Vondra writes:
> On 2/17/24 01:57, jian he wrote:
>> On Sat, Feb 17, 2024 at 2:16 AM Tomas Vondra
>> wrote:
>>> 1) We already have pg_typeof() function, so maybe we should use a
>>> similar naming convention pg_basetypeof()?
>> I am ok with pg_basetypeof.
> An alternative approach would
On 2/17/24 01:57, jian he wrote:
> On Sat, Feb 17, 2024 at 2:16 AM Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> On 1/2/24 01:00, jian he wrote:
>>> On Mon, Dec 4, 2023 at 5:11 PM John Naylor wrote:
On Thu, Sep 28, 2023 at 12:22 AM Alexander Korotkov
wrote:
> The one thing
On 17.02.2024 00:44, Tom Lane wrote:
"David G. Johnston" writes:
Per the recent bug report, we should probably add something like (ignored)
after the 50 connections for role1 since they are not allowed to login so
the value is indeed ignored. It is ignored to zero as opposed to unlimited
for
While analyzing a customer's performance problem, I noticed that
the performance of pg_dump for large arrays is terrible.
As a test case, I created a table with 1 rows, each of which
had an array of 1 uuids. The table resided in shared buffers.
The following took 24.5 seconds:
COPY
Hi Nathan!
(v18)
>I might be alone on this, but I think this command should output the same
>columns regardless of the version, whether it's using SSL, etc. and just
>put NULL in any that do not apply. IMHO that would simplify the code and
>help prevent confusion. Plus, I'm not aware of any
On Fri, Feb 16, 2024 at 9:09 PM Nathan Bossart
wrote:
> On Fri, Feb 16, 2024 at 01:45:52PM +0100, Mats Kindahl wrote:
> > Looks good to me.
>
> Committed.
>
Thanks Nathan!
>
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
>
21 matches
Mail list logo
