uple pre-existing TODOs.
I started work on some of these, but wasn't able to finish this
evening, so I don't have an updated series yet.
> James, what's your plan with this patch. Do you intend to work on it for
> PG16, or are there some issues I missed in the thread?
I'
On Fri, Mar 25, 2022 at 4:40 PM Robert Haas wrote:
>
> On Tue, Jan 25, 2022 at 8:49 AM James Coleman wrote:
> > Here's a version that looks like that. I'm not convinced it's an
> > improvement over the previous version: again, I expect more advanced
> > u
On Fri, Mar 25, 2022 at 5:00 PM Tom Lane wrote:
>
> Robert Haas writes:
> > I vote for rejecting both of these patches.
>
> I see what James is on about here, but I agree that these specific changes
> don't help much. What would actually be desirable IMO is a se
On Sun, Mar 27, 2022 at 11:43 AM Robert Haas wrote:
>
> On Sat, Mar 26, 2022 at 6:25 PM James Coleman wrote:
> > I simply do not accept the claim that this is not a reasonable concern
> > to have nor that this isn't worth documenting.
>
> I don't think I said
On Sun, Mar 27, 2022 at 1:46 PM David G. Johnston
wrote:
>
> On Sun, Mar 27, 2022 at 10:00 AM James Coleman wrote:
>>
>> As shown above, table scans (and specifically table scans used to
>> validate constraints, which is what this patch is about) are clearly
>> d
On Mon, Mar 28, 2022 at 9:30 AM Robert Haas wrote:
>
> On Sun, Mar 27, 2022 at 1:00 PM James Coleman wrote:
> > So "undocumented concept" is just not accurate, and so I don't see it
> > as a valid reason to reject the patch.
>
> I mean, I think it's
On Sun, Mar 27, 2022 at 11:12 PM David G. Johnston
wrote:
>
> On Sun, Mar 27, 2022 at 11:17 AM James Coleman wrote:
>>
>> Hmm, I didn't realize that was project policy,
>
>
> Guideline/Rule of Thumb is probably a better concept.
Ah, OK, thanks.
>>
>&g
ate the docs to match the current behavior.
Thanks,
James Coleman
From f6515a5f5f39d728b4cad837480c3ca953ed4623 Mon Sep 17 00:00:00 2001
From: jcoleman
Date: Tue, 29 Mar 2022 13:56:39 +
Subject: [PATCH v1] Docs: When table rewriting is skipped indexes are not
rebuilt
In 367bc42 (for 9.2!) we a
ted the slight correction in "Correct docs re:
rewriting indexes when table rewrite is skipped" [2] here, and will
rebase this patch if that gets committed.
Thanks,
James Coleman
1:
https://www.postgresql.org/message-id/CAKFQuwZyBaJjNepdTM3kO8PLaCpRdRd8%2BmtLT8QdE73oAsGv8Q%40mail.gmail.com
2
On Tue, Mar 29, 2022 at 11:29 AM Matthias van de Meent
wrote:
>
> On Tue, 29 Mar 2022 at 16:04, James Coleman wrote:
> >
> > Back in 367bc42 (for 9.2!) we "avoid[ed] index rebuild[ing] for
> > no-rewrite ALTER TABLE
> > .. ALTER TYPE." However the d
On Wed, Mar 30, 2022 at 11:41 AM Robert Haas wrote:
>
> On Wed, Mar 30, 2022 at 10:04 AM James Coleman wrote:
> > Admittedly I hadn't thought of that case. But isn't it already covered
> > in the existing docs by the phrase "or an unconstrained domain over
&g
On Wed, Mar 30, 2022 at 5:41 PM Robert Haas wrote:
>
> On Wed, Mar 30, 2022 at 4:33 PM James Coleman wrote:
> > Hmm, having it match the way it works makes sense. Would you feel
> > comfortable with an intermediate step (queueing up that as a larger
> > change) changing
On Thu, Mar 31, 2022 at 9:43 AM Robert Haas wrote:
>
> On Thu, Mar 31, 2022 at 9:17 AM James Coleman wrote:
> > All right, thanks for feedback. Attached is v2 with such a change.
> > I've not included examples, and I'm about 50/50 on doing so. What are
> > your
On Thu, Mar 31, 2022 at 10:29 AM Robert Haas wrote:
>
> On Thu, Mar 31, 2022 at 10:14 AM James Coleman wrote:
> > Is the attached more along the lines of what you were thinking?
>
> Yeah. Maybe this would be a little clearer: "For example, if the
> collation for a c
On Thu, Mar 31, 2022 at 3:25 PM Robert Haas wrote:
>
> On Thu, Mar 31, 2022 at 10:51 AM James Coleman wrote:
> > Updated.
>
> This version looks fine to me. If nobody objects I will commit it and
> credit myself as a co-author.
Sounds great; thanks again for the review.
James Coleman
On Fri, Apr 1, 2022 at 8:58 AM Robert Haas wrote:
>
> On Thu, Mar 31, 2022 at 4:19 PM James Coleman wrote:
> > On Thu, Mar 31, 2022 at 3:25 PM Robert Haas wrote:
> > > On Thu, Mar 31, 2022 at 10:51 AM James Coleman wrote:
> > > > Updated.
> > >
>
On Thu, Mar 31, 2022 at 10:58 AM Matthias van de Meent
wrote:
>
> On Tue, 29 Mar 2022 at 16:20, James Coleman wrote:
> >
> > Over in the "Document atthasmissing default optimization avoids
> > verification table scan" thread David Johnston (who I've cc&
auto_explain and
> see its feasibility.
>
> >>> There is a lot of similarity between what this feature does and what
> >>> auto explain does. I see the code is also duplicated. There is some
> >>> merit in avoiding this duplication
> >>> 1. we will get a
o run the "x, y" case as well as the "y, x" case
with a single call so as to eliminate a lot of repetition in
clause/expression test cases. If reviewers agree that's desirable, then I
could do that as a precursor.
Regards,
James Coleman
v1-0001-Teach-predtest-about-IS-NOT-bool-proofs.patch
Description: Binary data
Thanks for taking a look!
On Wed, Dec 13, 2023 at 1:36 PM Tom Lane wrote:
>
> James Coleman writes:
> > Attached is a patch that solves that issue. It also teaches predtest about
> > quite a few more cases involving BooleanTest expressions (e.g., how they
> > relate
Hi All, not sure how to "Specify thread msgid" - choose one which i think is
close to my new feature request.
query:
SELECT count(1) FROM table1 t1 JOIN table2 t2 ON t1.id = t2.id WHERE
t1.a_indexed_col='some_value' OR t2.a_indexed_col='some_vable';
can the server automatically replace the O
On Thu, Dec 14, 2023 at 4:38 PM Tom Lane wrote:
>
> James Coleman writes:
> > On Wed, Dec 13, 2023 at 1:36 PM Tom Lane wrote:
> >> I don't have an objection in principle to adding more smarts to
> >> predtest.c. However, we should be wary of slowing down c
On Tue, Sep 5, 2023 at 9:59 AM torikoshia wrote:
>
> On 2023-08-28 22:47, James Coleman wrote:
> > On Mon, Aug 28, 2023 at 3:01 AM torikoshia
> > wrote:
> >>
> >> On 2023-08-26 21:03, James Coleman wrote:
> >> > On Fri, Aug 25, 2023 at 7:43 AM Jame
On Tue, Sep 5, 2023 at 1:40 PM Melanie Plageman
wrote:
>
> On Wed, Jun 21, 2023 at 8:51 AM James Coleman wrote:
> > While at PGCon I was chatting with Andres (and I think Peter G. and a
> > few others who I can't remember at the moment, apologies) and Andres
ng this correctly, attached is a patch
correcting the description.
Thanks,
James Coleman
v1-0001-Correct-HOT-docs-to-account-for-LP_REDIRECT.patch
Description: Binary data
On Fri, Sep 29, 2023 at 2:26 PM Bruce Momjian wrote:
>
> On Mon, Jan 23, 2023 at 06:42:45PM -0500, James Coleman wrote:
> > On Mon, Jan 23, 2023 at 4:07 PM James Coleman wrote:
> > >
> > > On Mon, Jan 23, 2023 at 3:41 PM Robert Haas wrote:
> > > >
>
ten -- which would
include the first time a heap-only tuple is written. And when it's the
first heap-only tuple the "old version" would be the original version,
which would not be a heap-only tuple.
I can work up a tweaked version of the patch that shows there are two
paths here (original tuple is being updated versus an intermediate
heap-only tuple is being updated); would you be willing to consider
that?
Thanks,
James Coleman
On Fri, Sep 29, 2023 at 4:06 PM Peter Geoghegan wrote:
>
> On Fri, Sep 29, 2023 at 11:45 AM James Coleman
> wrote:my reading the issue is that "old versions" doesn't say
> > anything about "old HOT versions; it seems to be describing what
> > happens ge
On Thu, Sep 7, 2023 at 2:09 AM torikoshia wrote:
>
> On 2023-09-06 11:17, James Coleman wrote:
>
> >> > I've never been able to reproduce it (haven't tested the new version,
> >> > but v28 at least) on my M1 Mac; where I've reproduced it is
o continue to give correct
> > answers. So it is pretty strongly implied that it continues to point
> > to something valid.
>
> I took a look at this. I agree with James that the current wording is
> just plain wrong.
>
> periodic vacuum operations. (This is possible beca
On Wed, Oct 4, 2023 at 9:18 AM Robert Haas wrote:
>
> On Tue, Oct 3, 2023 at 3:35 PM James Coleman wrote:
> > I like your changes. Reading through this several times, and noting
> > Peter's comments about pruning being more than just HOT, I'm thinking
> > that r
On Tue, Sep 26, 2023 at 8:30 AM James Coleman wrote:
>
> On Tue, Sep 5, 2023 at 1:40 PM Melanie Plageman
> wrote:
> >
> > On Wed, Jun 21, 2023 at 8:51 AM James Coleman wrote:
> > > While at PGCon I was chatting with Andres (and I think Peter G. and a
> > >
On Wed, Oct 4, 2023 at 9:42 AM Robert Haas wrote:
>
> On Wed, Oct 4, 2023 at 9:36 AM James Coleman wrote:
> > Are you thinking we should simply elide the fact that there is pruning
> > that happens outside of HOT? Or add that information onto the HOT
> > page, even though
Hi,
Thanks for taking a look!
On Fri, Oct 6, 2023 at 1:18 AM Dilip Kumar wrote:
>
> On Thu, Oct 5, 2023 at 2:35 AM James Coleman wrote:
> >
> > I talked to Andres and Peter again today, and out of that conversation
> > I have some observations and ideas for future impr
On Fri, Oct 6, 2023 at 8:58 AM torikoshia wrote:
>
> On 2023-10-04 03:00, James Coleman wrote:
> > On Thu, Sep 7, 2023 at 2:09 AM torikoshia
> > wrote:
> >>
> >> On 2023-09-06 11:17, James Coleman wrote:
> >>
> >> >> > I
igint, c bigint, d bigint);
>INSERT INTO t SELECT
> 1000*random(), 1000*random(), 1000*random(), 1000*random()
>FROM generate_series(1,1000) s(i);
>CREATE INDEX idx ON t(a,b);
>ANALYZE t;
>
>EXPLAIN ANALYZE SELECT a, b, c, d, count(*)
>FROM (SELECT * F
On Fri, Mar 13, 2020 at 2:23 PM James Coleman wrote:
>
> On Tue, Mar 10, 2020 at 10:44 PM Tomas Vondra
> wrote:
> > 3) Most of the execution plans look reasonable, except that some of the
> > plans look like this:
> >
> >
> &g
On Friday, March 13, 2020, Tomas Vondra
wrote:
> On Fri, Mar 13, 2020 at 04:31:16PM -0400, James Coleman wrote:
>
>> On Fri, Mar 13, 2020 at 2:23 PM James Coleman wrote:
>>
>>>
>>> On Tue, Mar 10, 2020 at 10:44 PM Tomas Vondra
>>> wrote:
>>
On Fri, Mar 13, 2020 at 8:23 PM James Coleman wrote:
>
> On Friday, March 13, 2020, Tomas Vondra wrote:
>>
>> On Fri, Mar 13, 2020 at 04:31:16PM -0400, James Coleman wrote:
>>>
>>> On Fri, Mar 13, 2020 at 2:23 PM James Coleman wrote:
>>>>
>>
On Sat, Mar 14, 2020 at 12:07 PM James Coleman wrote:
>
> On Fri, Mar 13, 2020 at 8:23 PM James Coleman wrote:
> >
> > On Friday, March 13, 2020, Tomas Vondra
> > wrote:
> >>
> >> On Fri, Mar 13, 2020 at 04:31:16PM -0400, James Coleman wrote:
> &g
On Sat, Mar 14, 2020 at 12:24 PM James Coleman wrote:
>
> On Sat, Mar 14, 2020 at 12:07 PM James Coleman wrote:
> >
> > On Fri, Mar 13, 2020 at 8:23 PM James Coleman wrote:
> > >
> > > On Friday, March 13, 2020, Tomas Vondra
> > > wrote:
> >
On Sat, Mar 14, 2020 at 12:36 PM James Coleman wrote:
>
> On Sat, Mar 14, 2020 at 12:24 PM James Coleman wrote:
> >
> > On Sat, Mar 14, 2020 at 12:07 PM James Coleman wrote:
> > >
> > > On Fri, Mar 13, 2020 at 8:23 PM James Coleman wrote:
> > > >
On Fri, Mar 13, 2020 at 1:06 PM James Coleman wrote:
>
> On Thu, Mar 12, 2020 at 5:53 PM Alvaro Herrera
> wrote:
> >
> > I gave this a very quick look; I don't claim to understand it or
> > anything, but I thought these trivial cleanups worthwhile. The only
&g
On Sat, Mar 14, 2020 at 10:55 PM James Coleman wrote:
>
> On Fri, Mar 13, 2020 at 1:06 PM James Coleman wrote:
> >
> > On Thu, Mar 12, 2020 at 5:53 PM Alvaro Herrera
> > wrote:
> > >
> > > I gave this a very quick look; I don't claim to under
ind a better workflow.
How does the buildfarm automate generating the typedefs list? Would it
be relatively easy to incorporate that into a tool that someone could
use locally with pgindent?
Thanks,
James
hanges
- Added a basic commit message.
- Add unfetched_pages initialization to ExecInitBitmapHeapScan.
See attached.
Thanks,
James
From 95babe8447eadb40c2d1452a9102d4766269d80f Mon Sep 17 00:00:00 2001
From: James Coleman
Date: Sun, 15 Mar 2020 20:27:19 -0400
Subject: [PATCH v3] Show bitmap only
tuplesorts.
The approach I took was to show both average and max for both disk and
memory usage as well as all sort strategies used. It looks like this:
-> Incremental Sort
Sort Key: a, b
Presorted Key: a
Full-sort Groups: 4 (Methods: quicksort) Memory: 26kB (avg
ed the answer was
"no" (since if so I think it would follow that _all_ pages need
updated the first time they're vacuumed?). But if that's the case,
then this kind of opportunistic freezing wouldn't help this kind of
workload. Maybe there's something I'm misunderstanding about how
vacuum works though.
Thanks,
James
On Tue, Mar 17, 2020 at 11:37 PM Justin Pryzby wrote:
>
> On Tue, Mar 17, 2020 at 09:58:53PM -0400, James Coleman wrote:
> > On Tue, Mar 17, 2020 at 9:03 PM Andres Freund wrote:
> > >
> > > On 2020-03-17 20:42:07 +0100, Laurenz Albe wrote:
> > > > >
On Wed, Mar 18, 2020 at 1:08 PM Andres Freund wrote:
>
> Hi,
>
> On 2020-03-17 21:58:53 -0400, James Coleman wrote:
> > On Tue, Mar 17, 2020 at 9:03 PM Andres Freund wrote:
> > >
> > > Hi,
> > >
> > > On 2020-03-17 20:42:07 +0100, Laurenz
On Mon, Mar 16, 2020 at 9:08 AM James Coleman wrote:
> ...
> One question though: if I change the query to:
> explain (analyze, buffers) select count(*) from exp where a between 50
> and 100 and d between 5 and 10;
> then I get a parallel bitmap heap scan, and I only see exact hea
On Thu, Mar 19, 2020 at 9:26 PM Justin Pryzby wrote:
>
> On Mon, Mar 16, 2020 at 09:08:36AM -0400, James Coleman wrote:
> > Does the original optimization cover parallel bitmap heap scans like this?
>
> It works for parallel bitmap only scans.
>
> template1=# explain anal
bbreviate sort will be enabled, but it
> is disabled now.
>
> p.s. can be interesting repeat your tests with ICU locale where abbreviate
> sort is enabled.
Perhaps this is what you mean by "deterministic", but isn't it
possible for some collations to treat multiple byte sequences as equal
values? And those multiple byte sequences wouldn't necessarily occur
sequentially in C collation, so it wouldn't be possible to work around
that by having the grouping node use one collation but the sorting
node use the C one.
If my memory is incorrect, then this sounds like an intriguing idea.
James
me = tuplesort_method_name(methodCell->int_value);
So on the face of it we have a bit of a no-win situation. The function
tuple_sort_method_name returns a const, but lappend wants a non-const.
I'm not sure what the project style preference is here: we could cast
the result as (char *) to drop the const qualifier, but that's frowned
upon some places. Alternatively we could make a new non-const copy of
string. Which is preferable in the postgres project style?
James
On Sun, Mar 22, 2020 at 8:54 PM Andreas Karlsson wrote:
>
> On 3/23/20 1:33 AM, James Coleman wrote:
> > So on the face of it we have a bit of a no-win situation. The function
> > tuple_sort_method_name returns a const, but lappend wants a non-const.
> > I'm no
lot of clarification though they're "to avoid
confusion" about right/left inner/outer. I suppose if the
outerPlanState macro is working here the correct term should be outer?
Thanks,
James
tion Alvaro and Tom; I'll fix that up in
my next patch series.
I idly wonder if a macro childPlanState() defined exactly the same as
outerPlanState() might _kinda_ make sense here, but I'm also content
to follow convention.
I might submit a small patch to the comment on those macros though to
expand on the explanation.
James
On Tue, Mar 24, 2020 at 1:24 AM Amit Kapila wrote:
>
> On Fri, Mar 20, 2020 at 7:09 AM James Coleman wrote:
> >
> > Awesome, thanks for confirming with an actual plan.
> >
> > > I don't think it matters in nontext mode, but at least in text mode, I
> &
On Mon, Mar 23, 2020 at 11:44 PM Alvaro Herrera
wrote:
>
> On 2020-Mar-23, James Coleman wrote:
>
> > 4. nodeIncrementalSort.c ExecReScanIncrementalSort: This whole chunk
> > is suspect. I've mentioned previously I don't have a great mental
> > model of how
On Tue, Mar 24, 2020 at 7:08 PM Tomas Vondra
wrote:
>
> On Tue, Mar 24, 2020 at 06:26:11PM -0400, James Coleman wrote:
> >On Mon, Mar 23, 2020 at 11:44 PM Alvaro Herrera
> > wrote:
> >>
> >> On 2020-Mar-23, James Coleman wrote:
> >>
> >> >
On Tue, Mar 24, 2020 at 8:23 PM James Coleman wrote:
> While working on finding a test case to show rescan isn't implemented
> properly yet, I came across a bug. At the top of
> ExecInitIncrementalSort, we assert that eflags does not contain
> EXEC_FLAG_REWIND. But the following
ation to index scans that shows exactly this (how many pages we
were able to skip fetching). That approach actually can make things
more helpful than the approach current in explain for index only
scans, since the optimization isn't all or nothing (i.e., it can still
fetch heap pages), so it's interesting to see exactly how much it
gained you.
James
On Wed, Mar 25, 2020 at 3:19 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-09-18 13:51:00 -0400, James Coleman wrote:
> > In my experience it's not immediately obvious (even after reading the
> > documentation) the implications of how concurrent index builds manage
>
gative in reverse: if it actually is a scary
situation...this mutes your concern level. On the other hand,
monitoring would tell us if there's a real problem (namely replication
lag), so I think the trade-off is clearly worth it.
How about this minor tweak:
HINT: This is expected if this is the end of currently available WAL.
Otherwise, it could indicate corruption.
Thanks,
James
he root->query_pathkeys is
actually made up of eclass members for the current rel, because
otherwise I think we can skip the loop on the subpaths entirely.
> >> >I did notice though that find_em_expr_for_rel() is wholesale copied
> >> >(and unchanged) from the fdw code, s
On Fri, Mar 27, 2020 at 9:24 PM Amit Kapila wrote:
>
> On Wed, Mar 25, 2020 at 5:44 PM James Coleman wrote:
> >
> > On Tue, Mar 24, 2020 at 11:02 PM Amit Kapila
> > wrote:
> > >
> > > On Wed, Mar 25, 2020 at 12:44 AM Tom Lane wrote:
> > &g
er of paths in the loop
> is likely fairly low.
If what I said above is correct (and please poke holes in it if
possible), then I think we have to know the matching eclass count
anyway, so we might as well include the optimization since it'd be a
simple int comparison.
> >> >> >I did notice though that find_em_expr_for_rel() is wholesale
> >> >> >copied (and unchanged) from the fdw code, so I moved it to
> >> >> >equivclass.c so both places can share it.
> >> >> >
> >> >>
> >> >> +1
> >> >>
> >>
> >> ... which would also get rid of find_em_expr_for_rel().
> >
> >... which, I think, would retain the need for find_em_expr_for_rel().
> >
> >Note: The attached applied to the previous series compiles and runs
> >make check...but I haven't really tested it; it's meant more for "is
> >this the direction we want to go".
> >
>
> Thanks, I'll take a look.
James
On Sat, Mar 28, 2020 at 5:30 PM Tomas Vondra
wrote:
>
> On Sat, Mar 28, 2020 at 10:19:04AM -0400, James Coleman wrote:
> >On Fri, Mar 27, 2020 at 10:58 PM Tomas Vondra
> > wrote:
> >>
> >> ...
> >>
> >> The more I look
On Sat, Mar 28, 2020 at 11:14 PM Tomas Vondra
wrote:
>
> On Sat, Mar 28, 2020 at 10:47:49PM -0400, James Coleman wrote:
> >On Sat, Mar 28, 2020 at 6:59 PM Tomas Vondra
> > wrote:
> >>
> >> Hi,
> >>
> >> Attached is my take on simplific
uch
> fields "n" or "num". What about "nPresortedCols"? (Nitpicking, I know.)
I can fix this too.
Also I noticed a few compiler warnings I'll fixup in tomorrow's reply.
> My TODO for this patch is this:
>
> - review the costing (I think the estimates are OK, but I recall I
>haven't been entirely happy with how it's broken into functions.)
>
> - review the tuplesort changes (the memory contexts etc.)
>
> - do more testing of performance impact on planning
Sounds good.
Thanks,
James
On Tue, Mar 31, 2020 at 12:31 PM Alvaro Herrera
wrote:
>
> On 2020-Mar-30, James Coleman wrote:
>
> > +/*
> > + *Instruementation information for IncrementalSort
> > + *
> > + */
> > +typedef struct Incremen
On Tue, Mar 31, 2020 at 1:04 PM Tom Lane wrote:
>
> James Coleman writes:
> > + * TuplesortMethod is used in a bitmask in Increment Sort's shared memory
> > + * instrumentation so needs to have each value be a separate bit.
>
> >> I don't quite understand
On Tue, Mar 31, 2020 at 5:53 PM Tomas Vondra
wrote:
>
> On Tue, Mar 31, 2020 at 02:23:15PM -0400, James Coleman wrote:
> >On Mon, Mar 30, 2020 at 9:14 PM Tomas Vondra
> > wrote:
> >>
> >> The main thing I've been working on today is benchmarking how thi
ry and the index
was enough to save us ~4%.
Tomas: Earlier you'd wondered about if we should try to shortcut the
changes in costing...I was skeptical of that originally, but maybe
it's worth looking into? I'm going to try backing that out and see
what the numbers look like.
James
On Tue, Mar 31, 2020 at 7:56 PM Tomas Vondra
wrote:
>
> On Tue, Mar 31, 2020 at 07:09:04PM -0400, James Coleman wrote:
> >On Tue, Mar 31, 2020 at 6:54 PM Tomas Vondra
> > wrote:
> >>
> >> On Tue, Mar 31, 2020 at 06:35:32PM -0400, Tom Lane wrote:
> >>
On Tue, Mar 31, 2020 at 8:38 PM Tomas Vondra
wrote:
>
> On Tue, Mar 31, 2020 at 08:11:15PM -0400, James Coleman wrote:
> >On Tue, Mar 31, 2020 at 7:56 PM Tomas Vondra
> > wrote:
> >>
> >> On Tue, Mar 31, 2020 at 07:09:04PM -0400, James Coleman wrote:
> &g
On Tue, Mar 31, 2020 at 9:59 PM Tomas Vondra
wrote:
>
> On Tue, Mar 31, 2020 at 08:42:47PM -0400, James Coleman wrote:
> >On Tue, Mar 31, 2020 at 8:38 PM Tomas Vondra
> > wrote:
> >>
> >> On Tue, Mar 31, 2020 at 08:11:15PM -0400, James Coleman wrote:
> &g
cription? And if not, would
there be any reason why we would want to avoid exposing that
information? And if not, then would exposing it as a function be
acceptable?
Thanks,
James
On Wed, Apr 1, 2020 at 5:58 PM Alvaro Herrera wrote:
>
> On 2020-Apr-01, Tom Lane wrote:
>
> > James Coleman writes:
> > > To my knowledge the current oldest xmin (GetOldestXmin() if I'm not
> > > mistaken) isn't exposed directly in any view or
> Maybe it would make sense to start exposing fullXids in these views and
>> > functions, for this reason. There's no good reason to continue to
>> > expose bare Xids to userspace, we should use them only for storage.
>>
>> +1, that would help a lot.
>>
nefit" (at least in the short term) of using the
epoch/value style is that it makes (visual, at least) comparison with
other (32-bit) xid values easier.
I'm not sure if that's worth it, or if it's worth making a change
depend on changing all of those views too.
James
o be cost_sort)
> - cost_full_sort
> - cost_incremental_sort
> - cost_sort
>
> I find it a bit confusing that we have cost_sort and cost_full_sort. Why
> don't we just keep using the dummy path in label_sort_with_costsize?
> That seems to be the only external caller outside costsize.c. Then we
> could either make cost_full_sort static or get rid of it entirely.
This another area of the patch I haven't really modified.
James
[1]:
https://www.postgresql.org/message-id/flat/CAAaqYe-5HmM4ih6FWp2RNV9rruunfrFrLhqFXF_nrrNCPy1Zhg%40mail.gmail.com
On Thu, Apr 2, 2020 at 8:46 PM James Coleman wrote:
>
> On Thu, Apr 2, 2020 at 8:20 PM Tomas Vondra
> wrote:
> >
> > Hi,
> >
> > Thanks, the v52 looks almost ready. I've been looking at the two or
> > three things I mentioned, and I have
e message indicates
> hot_standby is off
> psql: error: could not connect to server: FATAL: the database system is
> starting up
> ...
> psql: error: could not connect to server: FATAL: the database system is up,
> but hot_standby is off
> ...
Thanks for the review and testing!
James
hat GUC, and fail in exactly that way with it.
> >
>
> Yes, there's a thinko in show_incremental_sort_info() and it returns too
> soon. I'll push a fix in a minute.
I'm stepping through this in a debugger; is what you're considering
that the for loop through the workers is off by one?
James
On Mon, Apr 6, 2020 at 5:20 PM James Coleman wrote:
>
> On Mon, Apr 6, 2020 at 5:12 PM Tomas Vondra
> wrote:
> >
> > On Mon, Apr 06, 2020 at 04:54:38PM -0400, Alvaro Herrera wrote:
> > >On 2020-Apr-06, Tom Lane wrote:
> > >
> > >> Locally, thin
On Mon, Apr 6, 2020 at 5:22 PM James Coleman wrote:
>
> On Mon, Apr 6, 2020 at 5:20 PM James Coleman wrote:
> >
> > On Mon, Apr 6, 2020 at 5:12 PM Tomas Vondra
> > wrote:
> > >
> > > On Mon, Apr 06, 2020 at 04:54:38PM -0400, Alvaro Herrera wr
fixsortGroupInfo->groupCount > 0
>
> but we won't print anything.
This shouldn't ever be possible, because the only way we get any
prefix groups at all is if we've already sorted a full sort group
during the mode transition.
> James, any opinion on this? I'd say we shou
On Mon, Apr 6, 2020 at 6:13 PM Tomas Vondra
wrote:
>
> On Mon, Apr 06, 2020 at 05:47:48PM -0400, James Coleman wrote:
> >On Mon, Apr 6, 2020 at 5:40 PM Tomas Vondra
> > wrote:
> >>
> >> On Mon, Apr 06, 2020 at 11:12:32PM +0200, Tomas Vondra wrote:
> >&
On Mon, Apr 6, 2020 at 7:09 PM James Coleman wrote:
>
> On Mon, Apr 6, 2020 at 6:13 PM Tomas Vondra
> wrote:
> >
> > On Mon, Apr 06, 2020 at 05:47:48PM -0400, James Coleman wrote:
> > >On Mon, Apr 6, 2020 at 5:40 PM Tomas Vondra
> > > wrote:
> > >&
On Mon, Jan 17, 2022 at 4:20 PM Robert Haas wrote:
>
> On Fri, Jan 14, 2022 at 7:42 PM James Coleman wrote:
> > I've attached a simple patch (sans tests and documentation) to get
> > feedback early. After poking around this afternoon it seemed to me
> > that the
On Mon, Jan 17, 2022 at 4:34 PM Alvaro Herrera wrote:
>
> On 2022-Jan-14, James Coleman wrote:
>
> > The logical slot can't flush past the
> > last commit, so even if there's 100s of megabytes of unflushed WAL on
> > the slot there may be zero lag (in te
On Tue, Jan 18, 2022 at 9:25 AM Robert Haas wrote:
>
> On Mon, Jan 17, 2022 at 8:39 PM James Coleman wrote:
> > I wondered about that, but commit_ts already does more than commit
> > timestamps by recording the xid of the last commit.
>
> Well, if you're maintaining
On Tue, Jan 18, 2022 at 12:50 PM Alvaro Herrera wrote:
>
> On 2022-Jan-17, James Coleman wrote:
>
> > I'd be happy to make it a separate GUC, though it seems adding an
> > additional atomic access is worse (assuming we can convince ourselves
> > putting
On Tue, Jan 18, 2022 at 1:52 PM Alvaro Herrera wrote:
>
> On 2022-Jan-18, James Coleman wrote:
>
> > Reading the code it seems the only usage (besides
> > the boolean activation status also stored there) is in
> > TransactionIdGetCommitTsData, and the only consumers of
e that. We'd also
> need to maintain a value for all disconnected backends, but that's also not a
> hot
> path.
I expect most monitoring setups default to around something like
checking anywhere from every single digit seconds to minutes.
If I read between the lines I imagine you'd see even e.g. every 2s as
not that big of a deal here, right?
Thanks,
James Coleman
be present if
track_commit_timestamps isn't on)? Or would you expect the current xid
and timestamp use the new infrastructure also?
Thanks,
James Coleman
On Tue, Jan 18, 2022 at 8:05 PM Andres Freund wrote:
>
> Hi,
>
> On 2022-01-18 18:31:42 -0500, James Coleman wrote:
> > One other question on this: if we went with this would you expect a
> > new function to parallel pg_last_committed_xact()?
>
> I don't think I
_xact() currently finds its home there.
I think we need a shared ProcArrayLock to read the array, correct? We
also need to do the global updating under lock, but given it's when a
proc is removed, that shouldn't be a performance issue if I'm
following what you are saying.
Thanks,
Jame
On Wed, Jan 19, 2022 at 7:51 PM David G. Johnston
wrote:
>
> On Wed, Jan 19, 2022 at 5:08 PM Bossart, Nathan wrote:
>>
>> On 9/24/21, 7:30 AM, "James Coleman" wrote:
>> > When PG11 added the ability for ALTER TABLE ADD COLUMN to set a constant
>> >
201 - 300 of 695 matches
Mail list logo
