On 8/20/21, 4:52 PM, "alvhe...@alvh.no-ip.org" wrote:
> On 2021-Aug-20, Bossart, Nathan wrote:
>
>> I was looking at moving the function calls out of the spinlock region.
>> I don't think the functions are doing anything too expensive, and they
>> help clean up NotifySegmentsReadyForArchive()
On Fri, Aug 20, 2021 at 11:42:09AM -0700, Mark Dilger wrote:
> These look correct.
static void
-help(const char *progname)
+help(const char *program_name)
These were discussed not long ago, and I recall that they were in the
we-don't-care category. Note for example all the tools of
src/scripts/
On Fri, Aug 20, 2021 at 11:35:29AM +0200, Ronan Dunklau wrote:
> Michael, your jsonlog module already fullfills this need. Is it something
> that
> should be merged into our tree ?
Yes, there is nothing technically preventing to have this stuff in
core, of course, and that would even take care
On 2021-Aug-20, Bossart, Nathan wrote:
> I was looking at moving the function calls out of the spinlock region.
> I don't think the functions are doing anything too expensive, and they
> help clean up NotifySegmentsReadyForArchive() quite a bit, but I
> understand why it might be against project
On 8/20/21, 4:00 PM, "alvhe...@alvh.no-ip.org" wrote:
> Attached is v14 which uses a separate spinlock.
This looks good to me.
I was looking at moving the function calls out of the spinlock region.
I don't think the functions are doing anything too expensive, and they
help clean up
Attached is v14 which uses a separate spinlock.
--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
"No me acuerdo, pero no es cierto. No es cierto, y si fuera cierto,
no me acuerdo." (Augusto Pinochet a una corte de justicia)
>From
On 2021-Aug-20, Bossart, Nathan wrote:
> > On Fri, Aug 20, 2021 at 1:29 PM Bossart, Nathan wrote:
> >> This led me to revisit the two-element
> >> approach that was discussed upthread. What if we only stored the
> >> earliest and latest segment boundaries at any given time? Once the
> >>
On Fri, Aug 20, 2021 at 3:40 PM Peter Geoghegan wrote:
> My concern here is really the data structure and its overall
> complexity. If there has to be an explicit state for every page on the
> FSM, then this new FSM needs to merge freelists that have been emptied
> into that structure, and needs
On Fri, Aug 20, 2021 at 3:32 PM Tomas Vondra
wrote:
> Yeah, I agree this seems like the right approach (except I guess you
> meant "a != a" and not "a != 0").
Err, yes.
> Assuming we want to do something about
> these clauses at all - I'm still wondering if those clauses are common
> in
Cary Huang writes:
> I also agree with Ashutosh that the "IS NOT TRUE" case can be simplified to
> just "IS FALSE". it's simpler to understand.
Uh ... surely that's just wrong?
regression=# select null is not true;
?column?
--
t
(1 row)
regression=# select null is false;
On Fri, Aug 20, 2021 at 12:20 PM Robert Haas wrote:
> On Fri, Aug 20, 2021 at 3:13 PM Peter Geoghegan wrote:
> > In short: yeah, this "closed vs open" page business more or less
> > necessitates tightening things up here. Though this new requirement
> > seems to have always been a good idea.
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Hello
I tried to apply the patch to master branch and got a
On 8/20/21 8:56 PM, Robert Haas wrote:
On Fri, Aug 20, 2021 at 2:21 PM Tomas Vondra
wrote:
After looking at this for a while, it's clear the main issue is handling
of clauses referencing the same Var twice, like for example (a = a) or
(a < a). But it's not clear to me if this is something
On Tue, Aug 17, 2021 at 02:14:20AM -0700, Andres Freund wrote:
> Doubling the number of UDP messages in common workloads seems also problematic
> enough that it should be addressed for 14. It increases the likelihood of
> dropping stats messages on busy systems, which can have downstream impacts.
On 8/18/21 12:43 PM, Tomas Vondra wrote:
Hi Mark,
This thread inspired me to do something fairly similar - a generator
that generates queries of varying complexity, executes them on table
with and without extended statistics. I've been thinking about that
before, but this finally pushed me
On Fri, Aug 20, 2021 at 3:13 PM Peter Geoghegan wrote:
> In short: yeah, this "closed vs open" page business more or less
> necessitates tightening things up here. Though this new requirement
> seems to have always been a good idea. Just because we can lean on
> VACUUM like this (an option that
On Fri, Aug 20, 2021 at 10:32 AM Peter Geoghegan wrote:
> But not storing information about a heap page implicitly means that
> the page is closed. And so we effectively remember the state of every
> single heap page with the FSM design I am working on. Not storing any
> information in the data
On Fri, Aug 20, 2021 at 2:21 PM Tomas Vondra
wrote:
> After looking at this for a while, it's clear the main issue is handling
> of clauses referencing the same Var twice, like for example (a = a) or
> (a < a). But it's not clear to me if this is something worth fixing, or
> if extended
> On Aug 20, 2021, at 11:19 AM, Daniel Gustafsson wrote:
>
> When perusing the pg_amcheck code the other day for the recently pushed fixes
> I
> found two small things that seem worth fixing: The help function progname
> parameter shadows the global variable of the same name, which no doubt
On Fri, Aug 20, 2021 at 1:52 PM alvhe...@alvh.no-ip.org
wrote:
> Actually, you were right. Hash tables in shared memory can be expanded.
> There are some limitations (the hash "directory" is fixed size, which
> means the hash table get less efficient if it grows too much), but you
> can
> On Aug 20, 2021, at 11:20 AM, Tomas Vondra
> wrote:
>
> I think we can either reject the patch, which would mean we don't consider
> (Var op Var) clauses to be common/important enough. Or we need to improve the
> existing selectivity functions (even those without extended statistics) to
On 8/18/21 3:16 PM, Mark Dilger wrote:
On Aug 18, 2021, at 3:43 AM, Tomas Vondra
wrote:
I've pushed everything (generator and results) to this github repo
Thanks for the link. I took a very brief look. Perhaps we can
combine efforts. I need to make progress on several other patches
When perusing the pg_amcheck code the other day for the recently pushed fixes I
found two small things that seem worth fixing: The help function progname
parameter shadows the global variable of the same name, which no doubt will
make static analyzers complain so we might as well fix that; and
On Fri, Aug 20, 2021 at 1:29 PM Bossart, Nathan wrote:
> Thinking about this stuff further, I was wondering if one way to
> handle the bounded shared hash table problem would be to replace the
> latest boundary in the map whenever it was full. But at that point,
> do we even need a hash table?
On 2021-Aug-20, Bossart, Nathan wrote:
> On 8/20/21, 8:29 AM, "Robert Haas" wrote:
> > We can't expand the hash table either. It has an initial and maximum
> > size of 16 elements, which means it's basically an expensive array,
> > and which also means that it imposes a new limit of 16 *
> >
> The rest of this email will be detailed review comments on the patch
> as presented, and thus probably only interesting to someone actually
> working on the patch. Feel free to skip if that's not you.
>
> - I suggest splitting the patch into one portion that deals with
> database OID and another
On Fri, Aug 20, 2021 at 10:15 AM Robert Haas wrote:
> > I guess that's true. Isn't this just semantics, though?
>
> Not entirely. On one level, as long as we end up with an FSM
> implementation that does good things, who cares how it works
> internally?
> I'd say "well, you should try
> to make
On 8/20/21, 10:08 AM, "Robert Haas" wrote:
> On Fri, Aug 20, 2021 at 12:36 PM Bossart, Nathan wrote:
>> If a record spans multiple segments, we only register one segment
>> boundary. For example, if I insert a record that starts at segment
>> number 1 and stops at 10, I'll insert one segment
On Fri, Aug 20, 2021 at 12:41 PM Pavel Stehule wrote:
> It can be fixed in 14. This is a low risk patch.
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Aug 20, 2021 at 12:17 PM Peter Geoghegan wrote:
> On Fri, Aug 20, 2021 at 9:03 AM Robert Haas wrote:
> > That could be the right decision, but nothing said up to this point
> > really seems to suggest it. The open/closed distinction and the
> > changes in how to bin available space could
On Thu, Aug 19, 2021 at 8:05 PM Jacob Champion wrote:
>
> On Thu, 2021-08-19 at 13:49 -0400, John Naylor wrote:
> > I had a couple further thoughts:
> >
> > 1. The coding historically used normal comparison and branching for
> > everything, but recently it only does that to detect control
> >
On Fri, Aug 20, 2021 at 12:36 PM Bossart, Nathan wrote:
> If a record spans multiple segments, we only register one segment
> boundary. For example, if I insert a record that starts at segment
> number 1 and stops at 10, I'll insert one segment boundary for segment
> 10. We'll only create
pá 20. 8. 2021 v 17:50 odesílatel Tom Lane napsal:
> In commit 2f48ede08 I copied some error-message wording that had
> existed in exec_run_select() since 2003. I'm now dissatified
> with that, after realizing that it can produce output like this:
>
> ERROR: query "WITH a AS (
> SELECT
>
On 8/20/21, 8:29 AM, "Robert Haas" wrote:
> On Fri, Aug 20, 2021 at 10:50 AM alvhe...@alvh.no-ip.org
> wrote:
>> 1. We use a hash table in shared memory. That's great. The part that's
>>not so great is that in both places where we read items from it, we
>>have to iterate in some way.
Em sex., 20 de ago. de 2021 às 12:29, Jelte Fennema <
jelte.fenn...@microsoft.com> escreveu:
> However, even if such an idea were to get the green light, I think I would
> take the obligatory regex jokes seriously, and instead use something like
> srcML [0] and do the analysis and modification on
On Fri, Aug 20, 2021 at 9:03 AM Robert Haas wrote:
> That could be the right decision, but nothing said up to this point
> really seems to suggest it. The open/closed distinction and the
> changes in how to bin available space could all be done with the
> present model.
I guess that's true.
On Fri, Aug 20, 2021 at 8:50 AM Tom Lane wrote:
> Thoughts? Should I back-patch this into v14 where 2f48ede08
> came in, or just do it in HEAD?
>
I'd say back-patch in the interest of preventing probably quite a few
emails from novices at plpgsql coding dealing with all the interplay
between
Hi Simon,
On 8/20/21 10:39 AM, Simon Riggs wrote:
Yeah, but it is a change to the protocol which means that the client
drivers and middleware ecosystem needs to be updated to support that
message.
No, because FE messages don't need to be handled by the client, they
just send them.
Yes, but
On Fri, Aug 20, 2021 at 11:48 AM Peter Geoghegan wrote:
> On Fri, Aug 20, 2021 at 7:45 AM Robert Haas wrote:
> > I very much doubt that you can get away without some sort of free
> > space map. Even if in most cases most pages are closed to insertions,
> > there will be important corner cases
Oops. I'm sorry. That previous email looked horrible in plaintext. Please
regard that as unsent. Same email, but second try:
> However, even if such an idea were to get the green light, I think I would
> take the obligatory regex jokes seriously, and instead use something like
> srcML [0] and do
On Fri, Aug 20, 2021 at 8:34 AM Robert Haas wrote:
> I expect they ran more than zero tests before selecting that value, so
> it's probably a decent choice in their system. However, that does seem
> rather low. I would have guessed that a good value would be in the
> 50-80 percent range.
They
In commit 2f48ede08 I copied some error-message wording that had
existed in exec_run_select() since 2003. I'm now dissatified
with that, after realizing that it can produce output like this:
ERROR: query "WITH a AS (
SELECT
regexp_split_to_table(info_out, '\n') AS info
FROM
On Fri, Aug 20, 2021 at 7:45 AM Robert Haas wrote:
> I very much doubt that you can get away without some sort of free
> space map. Even if in most cases most pages are closed to insertions,
> there will be important corner cases where lots of pages are open for
> insertions, like when you just
On Fri, Aug 20, 2021 at 11:06 AM Peter Geoghegan wrote:
> On Fri, Aug 20, 2021 at 7:32 AM Robert Haas wrote:
> > I don't know whether 60 is optimal or not, but it doesn't seem crazy.
>
> Uh, I had it right the first time. Only the fill factor setting is
> "inverted relative to Postgres". This
However, even if such an idea were to get the green light, I think I would
take the obligatory regex jokes seriously, and instead use something like
srcML [0] and do the analysis and modification on proper parse trees.
@Chapman I think that's a reasonable ask. This is the first time I heard of
On Fri, Aug 20, 2021 at 10:50 AM alvhe...@alvh.no-ip.org
wrote:
> 1. We use a hash table in shared memory. That's great. The part that's
>not so great is that in both places where we read items from it, we
>have to iterate in some way. This seems a bit silly. An array would
>serve
On Fri, Aug 20, 2021 at 7:32 AM Robert Haas wrote:
> I don't know whether 60 is optimal or not, but it doesn't seem crazy.
Uh, I had it right the first time. Only the fill factor setting is
"inverted relative to Postgres". This other setting really does
default to 40. So it's very low.
--
Two things.
1. We use a hash table in shared memory. That's great. The part that's
not so great is that in both places where we read items from it, we
have to iterate in some way. This seems a bit silly. An array would
serve us better, if only we could expand it as needed. However,
On Wed, Aug 18, 2021 at 1:05 PM Peter Geoghegan wrote:
> Maybe there isn't even a conventional FSM in this new world. Maybe
> free space management works by focusing on recent events, and on
> outcomes. This means that we store much less information about the
> entire database, and much more
On Fri, 20 Aug 2021 at 13:59, Jesper Pedersen
wrote:
>
> On 8/19/21 3:52 PM, Hannu Krosing wrote:
> > Jesper, please don't confuse my ramblings with Simon's initial proposal.
> >
> > As I understand, the original proposal was just about adding a new
> > wire protocol message type, which then
In v12 I moved the code around a bit and reworded some comments.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
>From 7d1475578431e265a5e7f8b94a6b0791b68a9a31 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 17 Aug 2021 03:52:43 +
Subject: [PATCH
On Wed, Aug 18, 2021 at 3:58 PM Peter Geoghegan wrote:
> On Tue, Aug 17, 2021 at 5:31 PM Peter Geoghegan wrote:
> > > Now what's the threshold? 20 out of 100? 50? 80?
> >
> > I'm not going to pretend to know the answer. But I will point out that
> > one DB system whose heap fill factor defaults
Em sex., 20 de ago. de 2021 às 09:18, Alexander Pyhalov <
a.pyha...@postgrespro.ru> escreveu:
> Ranier Vilela писал 2021-08-20 14:19:
>
> > Another question:
> > For 0002 patch:
> >
> > + if (node->funcid == F_NOW)
> > + {
> > + SQLValueFunction *svf = makeNode(SQLValueFunction);
> > +
> > +
On Fri, Aug 20, 2021 at 12:13 AM Alexander Pyhalov
wrote:
> Hi.
>
> Ranier Vilela писал 2021-08-19 14:01:
> > Em qui., 19 de ago. de 2021 às 07:50, Zhihong Yu
> >> Hi,
> >> For 0001 patch:
> >>
> >> + if ((s->op != SVFOP_CURRENT_TIMESTAMP) &&
> >> + (s->op !=
Hi Hannu,
On 8/19/21 3:52 PM, Hannu Krosing wrote:
Jesper, please don't confuse my ramblings with Simon's initial proposal.
As I understand, the original proposal was just about adding a new
wire protocol message type, which then could be used for emitting
custom messages by middleware support
On Tue, Aug 17, 2021 at 06:30:18AM -0500, Justin Pryzby wrote:
> On Mon, Aug 16, 2021 at 05:28:10PM -0500, Justin Pryzby wrote:
> > On Mon, Aug 16, 2021 at 05:42:48PM -0400, Álvaro Herrera wrote:
> > > On 2021-Aug-16, Álvaro Herrera wrote:
> > >
> > > > Here's the reversal patch for the 14
Ranier Vilela писал 2021-08-20 14:19:
Another question:
For 0002 patch:
+ if (node->funcid == F_NOW)
+ {
+ SQLValueFunction *svf = makeNode(SQLValueFunction);
+
+ svf->op = SVFOP_CURRENT_TIMESTAMP;
+ svf->type = TIMESTAMPTZOID;
+ svf->typmod = -1;
+ svf->location = -1;
+
+
On Thu, 19 Aug 2021 at 14:58, Andres Freund wrote:
>
> Hi,
>
> On 2021-08-19 14:47:42 +0200, Matthias van de Meent wrote:
> > I tried to implement this 'compact attribute access descriptor' a few
> > months ago in my effort to improve btree index performance.
>
> cool
>
>
> > The patch allocates
On 22.07.21 16:58, Fabien COELHO wrote:
Here is the updated version (v8? I'm not sure what the right count is),
which works for me and for "make check", including some tests added for
uncovered paths.
I included your tap test (thanks again!) with some more comments and
cleanup.
The tap
Em sex., 20 de ago. de 2021 às 04:13, Alexander Pyhalov <
a.pyha...@postgrespro.ru> escreveu:
> Hi.
>
> Ranier Vilela писал 2021-08-19 14:01:
> > Em qui., 19 de ago. de 2021 às 07:50, Zhihong Yu
> >> Hi,
> >> For 0001 patch:
> >>
> >> + if ((s->op != SVFOP_CURRENT_TIMESTAMP) &&
>
On 2021/08/20 11:53, Kyotaro Horiguchi wrote:
At Thu, 19 Aug 2021 20:29:42 +0900, Fujii Masao
wrote in
On 2021/08/19 17:03, Kyotaro Horiguchi wrote:
Hello.
While I was examining message translation for PG14, I found some
messages that would need to be fixed.
0001 is a fix for
Le jeudi 19 août 2021, 16:50:10 CEST Alvaro Herrera a écrit :
> On 2021-Aug-19, Magnus Hagander wrote:
> > Another thing I've noticed in more and more other products is to be
> > able to log as json, which is then later thrown into a central logging
> > system somewhere. Basically like csv, but
Le jeudi 19 août 2021, 15:04:30 CEST Alvaro Herrera a écrit :
> On 2021-Aug-13, Ronan Dunklau wrote:
> > ereport(NOTICE,
> >
> > (errmsg("My log message")),
> > (errtag("EMITTER", "MYEXTENSION")),
> > (errtag("MSG-ID", "%d", error_message_id))
> >
> > );
>
> Interesting idea. I agree this
> On Thursday, August 19, 2021 9:53 AM Masahiko Sawada
> wrote:
>
> Thank you for reporting the issue! This issue must be fixed in the
> latest (v9) patches I've just submitted[1].
>
Thanks for your patch.
I've confirmed the issue is fixed as you said.
Regards
Tang
On 22.07.21 18:18, Mark Dilger wrote:
On Jul 22, 2021, at 7:56 AM, Peter Eisentraut
wrote:
Please check that it's up to speed.
<0001-pg_amcheck-Fix-block-number-parsing-on-command-line.patch>
This looks correct to me. Thanks for the fix.
Committed this to 14 and master.
Your use of
On Sun, 25 Jul 2021 at 16:34, Pavel Stehule wrote:
>
>
> ne 25. 7. 2021 v 12:52 odesílatel Dinesh Chemuduru <
> dinesh.ku...@migops.com> napsal:
>
>> On Sat, 17 Jul 2021 at 01:29, Pavel Stehule
>> wrote:
>>
>>> Hi
>>>
>>> pá 16. 7. 2021 v 21:47 odesílatel Dinesh Chemuduru <
>>>
At Fri, 20 Aug 2021 16:23:56 +0900, Michael Paquier wrote
in
> On Fri, Aug 20, 2021 at 03:33:37PM +0900, Kyotaro Horiguchi wrote:
> > That's looks like a domino falling. I had the following result, which
> > looks fine.
> >
> > "WAL-Ranges": [
> > { "Timeline": 6, "Start-LSN": "0/630C7E8",
Hi.
Ashutosh Bapat писал 2021-08-19 17:01:
I spent some time looking at this patch.
Generally it looks like a good idea. These stable functions will be
evaluated at the execution time and replaced with constants. I am not
sure whether the nodes saved in the param_list may not get the same
On Fri, Aug 20, 2021 at 03:33:37PM +0900, Kyotaro Horiguchi wrote:
> That's looks like a domino falling. I had the following result, which
> looks fine.
>
> "WAL-Ranges": [
> { "Timeline": 6, "Start-LSN": "0/630C7E8", "End-LSN": "0/630C850" },
> { "Timeline": 5, "Start-LSN": "0/630C780",
Hi.
Ranier Vilela писал 2021-08-19 14:01:
Em qui., 19 de ago. de 2021 às 07:50, Zhihong Yu
Hi,
For 0001 patch:
+ if ((s->op != SVFOP_CURRENT_TIMESTAMP) &&
+ (s->op != SVFOP_CURRENT_TIMESTAMP_N) &&
+ (s->op != SVFOP_CURRENT_TIME) &&
...
The
Thank you for the comment.
At Thu, 19 Aug 2021 15:51:38 +0900, Michael Paquier wrote
in
> On Wed, Aug 18, 2021 at 02:30:31PM +0900, Kyotaro Horiguchi wrote:
> > The "Start-LSN" above is the beginning of timeline 2, not the
> > backup-start LSN. The segment had been removed by the checkpoint.
>
71 matches
Mail list logo
