> On 2 Jul 2024, at 20:55, Tom Lane wrote:
>
> Here's a cleaned-up code patch addressing the cfbot complaints
> and making the output logic a bit neater.
>
> I think this is committable code-wise, but the documentation needs
> work, if not indeed a complete rewrite. The examples are now
> ho
1.
> + BlockNumber vm_page_freezes;/* # pages newly set all-frozen in VM */
> + BlockNumber vm_page_visibles; /* # pages newly set all-visible in the
> VM */
I believe renaming the variables to ‘vm_freeze_pages’ and
‘vm_visible_pages’ would enhance readability and ensure consistency
wit
On Fri, Nov 1, 2024, at 22:28, Masahiko Sawada wrote:
> As I mentioned in a separate email, if we use the OS default EOL as
> the default EOL in raw format, it would not be necessary to allow it
> to be multi characters. I think it's worth considering it.
I like the idea, but not sure I understand
> Hi,
>
> I noticed an issue in the pgbench progress message where an extra
> closing parenthesis )) appears, as shown below:
>
> 700 of 1000 tuples (70%) of pgbench_accounts done (elapsed
> 19.75 s, remaining 8.46 s))
Yeah, annoying.
> This occurs when running commands like pgbench -i
Hi!
On 29.10.2024 14:02, Alena Rybakina wrote:
On 28.10.2024 16:40, Alexander Korotkov wrote:
On Sun, Aug 25, 2024 at 6:59 PM Alena Rybakina
wrote:
I didn't understand correctly - did you mean that we don't need SRF if
we need to display statistics for a specific object?
Otherwise, we need
so 2. 11. 2024 v 6:46 odesílatel Laurenz Albe
napsal:
> On Tue, 2024-10-29 at 08:16 +0100, Pavel Stehule wrote:
> > again, necessary rebase
>
> I have started looking at patch 5, and I have some questions and comments.
>
> - The commit message is headed "memory cleaning after DROP VARIABLE", but
Ashutosh Bapat writes:
> On Tue, Oct 29, 2024 at 10:49 PM Tom Lane wrote:
>> So what I now think
>> is that we ought to tweak the patch so that the parent alias is
>> pushed down only when the subquery contains just VALUES, no other
>> clauses. Per a look at the grammar, ORDER BY, LIMIT, and FOR
On 11/1/24 06:17, David Rowley wrote:
On Thu, 31 Oct 2024 at 15:30, Andrei Lepikhov wrote:
Comparing the master with and without your patch, the first, I see is
more extensive usage of memory (see complete explains in the attachment):
Current master:
Batches: 1 Memory Usage: 74513kB
Pa
On Wed, Oct 30, 2024 at 10:41 PM Junwang Zhao wrote:
>
> On Wed, Oct 30, 2024 at 10:17 PM Junwang Zhao wrote:
> >
> > Hi,
> >
> > On Wed, Oct 30, 2024 at 9:29 PM Aleksander Alekseev
> > wrote:
> > >
> > > Hi,
> > >
> > > Thanks for the updated patch set.
> > >
> > > > > > +Datum
> > > > > > +arr
Hi hackers,
While working on a rebase for [0], I noticed some weird behavior on the stats.
The issue is that [0], in conjonction with b14e9ce7d5, does introduce padding
in
the PgStat_HashKey:
(gdb) ptype /o struct PgStat_HashKey
/* offset |size */ type = struct PgStat_HashKey {
/*
Hi,
I notice that check the condtion again when after invoked process_equivalence
and return failed.
if (restrictinfo->mergeopfamilies)
{
if (maybe_equivalence)
{
if (process_equivalence(root, &restrictinfo, jtitem->jdomain))
{
/* distribute to base */
int relid;
if (bms_get_singleton_member(res
On Sat, Nov 2, 2024 at 12:02:12PM +0900, Tatsuo Ishii wrote:
> > Yes, we _allow_ LATIN1 characters in the SGML docs, but I replaced the
> > LATIN1 characters we had with HTML entities, so there are none
> > currently.
> >
> > I think it is too easy for non-Latin1 UTF8 to creep into our SGML docs
"Andrey M. Borodin" writes:
> This thread has associated CF entry which is marked as RwF [0]. But the
> change proved to be useful [1] in understanding what we can expect from time
> source.
> It was requested many times before [2,3]. Reading through this thread it
> seems to me that my questio
13 matches
Mail list logo
