On Sat, Mar 2, 2019 at 5:29 PM Tom Lane wrote:
>
> James Coleman writes:
> > On Fri, Mar 1, 2019 at 5:28 PM Tom Lane wrote:
> >> I also tweaked it to recognize the case where we can prove the
> >> array, rather than the scalar, to be null. I'm not sure how u
ch to document that behavior (as opposed to just in
the code at src/backend/storage/lmgr/proc.c:1320-1321).
James Coleman
autovacuum-interruption-v1.patch
Description: Binary data
On Tue, Jan 21, 2020 at 9:25 AM Tomas Vondra
wrote:
>
> Hi,
>
> This patch has been marked as WoA since end of November, and there has
> been no discussion/reviews since then :-( Based on off-list discussion
> with James I don't think that's going to change in this CF, so I'll move
> it to the nex
On Tue, Jan 21, 2020 at 9:58 AM Tomas Vondra
wrote:
>
> On Tue, Jan 21, 2020 at 09:37:01AM -0500, James Coleman wrote:
> >On Tue, Jan 21, 2020 at 9:25 AM Tomas Vondra
> > wrote:
> >>
> >> Hi,
> >>
> >> This patch has been marked as WoA since
changes you were
hoping to make after conversations you'd had with others? I'm hoping
for any pointers/context you have from those conversations as to what
you felt was necessary to get this change committed.
Thanks,
James Coleman
I've rebased the patch on master and confirmed make check world passes.
incremental-sort-27.patch
Description: Binary data
in not having to pull many more tuples in a
regular sort node, but the fallback logic kicks in anyway.
Unrelated to all of the above: if I read the patch properly it
intentionally excludes backwards scanning. I don't see any particular
reason why that ought to be the case, and it seems like an odd
limitation for the feature should it be merged. Should that be a
blocker to merging?
James Coleman
Bump, and curious if anyone on hackers has any ideas here: of particular
interest is why the (pk, created_at) index can possibly be more valuable
than the (created_at, pk) variant since the former effectively implies
having to scan the entire index.
On Fri, Sep 7, 2018 at 12:17 PM James Coleman
than continuing to execute?
Thanks,
James Coleman
Perfect. Thanks for the pointer, Andres, that's exactly what I was looking
for.
On Mon, Oct 15, 2018 at 1:28 PM Andres Freund wrote:
> Hi,
>
> On 2018-10-15 13:21:04 -0400, James Coleman wrote:
> > This my first real foray into the Postgres codebase, so an beginner
> >
n) into
tuple_data_{split,record}(). I'd appreciate feedback on this possibility.
TODO:
- Add documentation.
- Consider inlining _internal functions.
Thanks,
James Coleman
tuple-data-record-v1.patch
Description: Binary data
s like maybe the style guide could be a bit more
descriptive in some of these areas to be more friendly to newcomers. In
contrast the wiki page for submitting a patch is extremely detailed.
Thanks,
James Coleman
>
>
> I did compleatly got the question... The question is it safe to split
> tuple
> record into array of raw bytea? It is quite safe from my point of view.
> We
> use only data that is inside the tuple, and info from pg_catalog that
> describes the tuple structure. So we are not affected if for e
Indeed. But I do think your approach - which means that the binary data is
> actually interpreded as a datum of a specific type, drastically
> increases the risk.
>
>
Agreed.
As I noted earlier, I don't at all think deTOASTing is a must for this
function to be
valuable, just as tuple_data_split()
> It's far from only toast that could be problematic here.
>
Do you have an example in mind? Wouldn’t the tuples have to be corrupted in
some way to have problems with being interpreted as a datum? Or are you
thinking very old tuples with a radically different structure to be causing
the problem?
> There's plenty ways it can go horribly wrong. Let's start with something
> simple:
>
> BEGIN;
> ALTER TABLE ... ADD COLUMN blarg INT;
> INSERT ... (blag) VALUES (132467890);
> ROLLBACK;
>
> ALTER TABLE ... ADD COLUMN blarg TEXT;
>
> If you now read the table with your function you'll see a dead r
> I don't see why you'd get that error, if you re-add a column (with a
> different type), as I did above? Obviously the "replacement" column
> addition would need to be committed.
>
Here's my test case:
CREATE TABLE t3(i INTEGER);
BEGIN;
ALTER TABLE t3 ADD COLUMN blarg INT;
INSERT INTO t3(bla
a GUC knob?"
Status:
The attached patch applies cleanly to master, builds without error,
and passes tests locally.
Thanks,
James Coleman
array_optimization_size_limit_guc-v1.patch
Description: Binary data
Should I add additional tests for predtest? It already seems to cover some
null
test cases with scalar array ops, but I'd be happy to add more if desired.
Should I add a test case for the resulting plan with "foo IN (...)" with an
array with more than 100 elements?
Thanks,
James Coleman
saop_is_not_null-v1.patch
Description: Binary data
Note: the original email from David went to my spam folder, and it also
didn't show up on the archives (I assume caught by a spam filter there
also?)
Thanks for taking this on!
>
> As far as you can tell, is the default correct at 100?
>
I'm not sure what a good way of measuring it would be (that
master if you remove items from the test array to make the array <=
100 items) as well as a comment detailing the reasoning in predtest.c.
On Sat, Nov 10, 2018 at 4:33 PM James Coleman wrote:
>
> I've recently been investigating improving our plans for queries like:
> SELECT *
Also, my apologies for top posting; I forgot to remove the old email
before clicking send.
> Is skip scan only possible for index-only scan?
I haven't see much discussion of this question yet. Is there a
particular reason to lock ourselves into thinking about this only in
an index only scan?
>> I think we can improve this,
>> and the skip scan can be strictly faster than index scan reg
> > My main comment is that the description of the purpose of the GUC doesn't
> > help me understand when or why I might want to alter it from the default
> > value. If nobody is going to alter it, because nobody understands it, it
> > might as well remain a compile-time constant.
>
> Yeah, that's
>> I'd be happy to yank this in favor of my holistic solution to this
>> problem I posted recently on the mailing list [1].
>
> [1]
> https://www.postgresql.org/message-id/flat/CAAaqYe8yKSvzbyu8w-dThRs9aTFMwrFxn_BkTYeXgjqe3CbNjg%40mail.gmail.com
>
> Not precisely sure what you mean - are you sayin
On Fri, Dec 22, 2023 at 2:48 PM Tom Lane wrote:
>
> James Coleman writes:
> > I've not yet applied all of your feedback, but I wanted to get an
> > initial read on your thoughts on how using switch statements ends up
> > looking. Attached is a single (pure refa
mit_lsn() is marked as STABLE which is
> probably correct. But I would appreciate a second opinion on this.
Sounds good.
> - Wouldn't it be appropriate to add a test or two?
Added.
> - `if (!XLogRecPtrIsInvalid(commit_lsn))` - I suggest adding
> XLogRecPtrIsValid() macro for better read
On Sun, Jan 14, 2024 at 6:01 AM vignesh C wrote:
>
> On Sat, 10 Jun 2023 at 07:57, James Coleman wrote:
> >
> > I've previously noted in "Add last commit LSN to
> > pg_last_committed_xact()" [1] that it's not possible to monitor how
> > many
cation on the read column the error is more understandable:
ERROR: column reference "bar" is ambiguous
It seems to me that it'd be desirable to either allow the unnecessary
qualification or give an error that's more easily understood.
Regards,
James Coleman
On Fri, Jan 19, 2024 at 1:53 PM David G. Johnston
wrote:
>
> On Fri, Jan 19, 2024 at 10:01 AM James Coleman wrote:
>>
>> Making this more confusing is the fact that if I want to do something
>> like "SET bar = foo.bar + 1" the table qualification cannot be prese
On Sat, Jan 20, 2024 at 11:12 AM Tom Lane wrote:
>
> James Coleman writes:
> > Suppose I have this table:
> > create table foo (id int primary key);
>
> > On PG11 this works:
> > postgres=# insert into foo (id) values (1) on conflict (id) do update
> > set
On Sat, Jan 20, 2024 at 12:59 PM Tom Lane wrote:
>
> James Coleman writes:
> > I do wonder if it's plausible (and sufficiently easy) to improve the
> > error message here. "column 'foo' of relation 'foo'" makes one thing
> > that you&#
On Sat, Jan 20, 2024 at 5:57 PM Tom Lane wrote:
>
> James Coleman writes:
> > On Sat, Jan 20, 2024 at 12:59 PM Tom Lane wrote:
> >> A HINT if the bogus column name (1) matches the relation name and
> >> (2) is field-qualified seems plausible to me. Then it
f necessary.
>
> ==
> [1]
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/46/4355
>
> Kind Regards,
> Peter Smith.
Updated patch attached,
Thanks,
James Coleman
v3-0001-Add-last-commit-s-LSN-to-pg_stat_database.patch
Description: Binary data
f necessary.
>
> ==
> [1] https://commitfest.postgresql.org/46/4384//
> [2]
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/46/4384
See rebased patch attached.
Thanks,
James Coleman
v3-0001-Allow-getting-lock-before-calling-heap_page_prune.patch
Descripti
On Mon, Jan 22, 2024 at 8:21 PM James Coleman wrote:
>
> See rebased patch attached.
I just realized I left a change in during the rebase that wasn't necessary.
v4 attached.
Regards,
James Coleman
v4-0002-Opportunistically-prune-to-avoid-building-a-new-p.patch
Description: Binar
On Tue, Jan 23, 2024 at 2:46 AM Dilip Kumar wrote:
>
> On Tue, Jan 23, 2024 at 7:18 AM James Coleman wrote:
> >
> > On Mon, Jan 22, 2024 at 8:21 PM James Coleman wrote:
> > >
> > > See rebased patch attached.
> >
> > I just realized I left a c
On Fri, Jan 26, 2024 at 8:33 PM James Coleman wrote:
>
> On Tue, Jan 23, 2024 at 2:46 AM Dilip Kumar wrote:
> >
> > On Tue, Jan 23, 2024 at 7:18 AM James Coleman wrote:
> > >
> > > On Mon, Jan 22, 2024 at 8:21 PM James Coleman wrote:
> > > >
&
ross worker boundaries. However
looking at the diff in the patch at that point (v10) that particular
test query formed a different plan shape (there were two gather nodes
being created, and params crossing between them).
But in the current revision of master with the current patch applied
that's
so there's been nothing to reply to.
That being said, Vignesh's note in January about a now-failing test is
relevant activity, and I've just today responded to that, so I'm
changing the status back from Waiting on Author to Needs Review.
Regards,
James Coleman
On Tue, Jan 30, 2024 at 10:34 PM Tom Lane wrote:
>
> James Coleman writes:
> > I've finally had a chance to look at this, and I don't believe there's
> > any real failure here, merely drift of how the planner works on master
> > resulting in this query
e any reason why this
couldn't happen separately. That being said, on master I don't have a
case showing this is necessary.
Thanks,
James Coleman
1:
https://www.postgresql.org/message-id/flat/CAAaqYe-Aq6oNf9NPZnpPE7SgRLomXXWJA1Gz9L9ndi_Nv%3D94Yw%40mail.gmail.com#e0b1a803d0fdb971
On Wed, Jan 31, 2024 at 3:18 PM Robert Haas wrote:
>
> On Tue, Jan 30, 2024 at 9:56 PM James Coleman wrote:
> > I don't follow the "Idle since July" since it just hasn't received
> > review since then, so there's been nothing to reply to.
>
> It
On Thu, Feb 1, 2024 at 1:36 AM Richard Guo wrote:
>
>
> On Thu, Feb 1, 2024 at 11:37 AM David Rowley wrote:
>>
>> On Thu, 1 Feb 2024 at 16:29, Richard Guo wrote:
>> > On Thu, Feb 1, 2024 at 10:04 AM James Coleman wrote:
>> >> I don't see any
ble.
I'm wondering if this might be a surprise to anyone else, and if so,
is there a minor docs tweak that might avoid the confusion?
Thanks,
James Coleman
1:
https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-REPLICA-IDENTITY
2: https://www.postgresql.org/docs/current/logical-replication-publication.html
On Wed, Feb 7, 2024 at 3:22 PM Laurenz Albe wrote:
>
> On Wed, 2024-02-07 at 15:12 -0500, James Coleman wrote:
> > We recently noticed some behavior that seems reasonable but also
> > surprised our engineers based on the docs.
> >
> > If we have this setup
On Wed, Feb 7, 2024 at 6:04 PM Peter Smith wrote:
>
> On Thu, Feb 8, 2024 at 9:04 AM James Coleman wrote:
> >
> > On Wed, Feb 7, 2024 at 3:22 PM Laurenz Albe
> > wrote:
> > >
> > > On Wed, 2024-02-07 at 15:12 -0500, James Coleman wrote:
> >
or index that doesn't exist) is added ...
I think that would work also. I was reading the initial suggestion as
"(or with replica identity behavior the same as..." as defining what
"without a replica identity" meant, which would avoid the confusion.
But your proposal is more explicit and more succinct, so I think it's
the better option of the two.
Regards,
James Coleman
> NOTHING
>
> Records no information about the old row. This is equivalent to having
> no replica identity. This is the default for system tables.
This is the simplest change, and it does solve the confusion, so I'd
be happy with it also. The other proposals have the benefit of having
all the information necessary on the publications page rather than
requiring the user to refer to the ALTER TABLE REPLICA IDENTITY page
to understand what's meant.
Regards,
James Coleman
On Mon, Feb 27, 2023 at 2:33 AM Heikki Linnakangas wrote:
>
> On 16/11/2022 07:17, kuroda.keis...@nttcom.co.jp wrote:
> >> The issue here is pg_rewind looks into control file to determine the
> >> soruce timeline, because the control file is not updated until the
> >> first checkpoint ends after p
On Thu, Mar 14, 2024 at 10:28 AM Robert Haas wrote:
>
> On Wed, Oct 4, 2023 at 9:12 PM James Coleman wrote:
> > All right, attached is a v3 which attempts to fix the wrong
> > information with an economy of words. I may at some point submit a
> > separate patch tha
On Wed, Mar 20, 2024 at 2:15 PM Robert Haas wrote:
>
> On Thu, Mar 14, 2024 at 9:07 PM James Coleman wrote:
> > Obviously I have reasons for the other changes I made: for example,
> > "no longer visible" improves the correctness, since being an old
> > version i
On Thu, Mar 21, 2024 at 1:09 PM Robert Haas wrote:
>
> On Thu, Mar 14, 2024 at 9:07 PM James Coleman wrote:
> > If the goal here is the most minimal patch possible, then please
> > commit what you proposed. I am interested in improving the document
> > further, but I d
tant, but perhaps future readers of the archives will
> be confused.
I was wondering myself :) so thanks for clarifying.
Regards,
James Coleman
On Mon, Mar 25, 2024 at 5:53 PM Tom Lane wrote:
>
> James Coleman writes:
> > [ v6 patchset ]
>
> I went ahead and committed 0001 after one more round of review
>
> statements; my bad). I also added the changes in test_predtest.c from
> 0002. I attach a rebased versi
On Mon, Apr 1, 2024 at 8:06 AM James Coleman wrote:
>
> On Mon, Mar 25, 2024 at 5:53 PM Tom Lane wrote:
> >
> > James Coleman writes:
> > > [ v6 patchset ]
> >
> > I went ahead and committed 0001 after one more round of review
> >
> >
ewhere. That's not likely to ever be as stable as we want
> PostgreSQL to be.
This is potentially a bit of a wild idea, but I wonder if having some
kind of argument to CHECK_FOR_INTERRUPTS() signifying we're in
"normal" as opposed to "critical" (using that word differently than
the existing critical sections) would be worth it.
Regards,
James Coleman
On Fri, Feb 23, 2024 at 10:23 AM Robert Haas wrote:
>
> On Fri, Feb 23, 2024 at 7:50 PM Julien Rouhaud wrote:
> > On Fri, Feb 23, 2024 at 10:22:32AM +0530, Robert Haas wrote:
> > > On Thu, Feb 22, 2024 at 6:25 AM James Coleman wrote:
> > > > This is potent
>
> If this is correctly implemented, the overhead in the case where the
> feature isn't used should be essentially zero, I believe.
If I can rephrase this idea: it's basically "delay this interrupt
until inline to the next ExecProcNode execution".
That seems pretty promising to me as well.
Regards,
James Coleman
t; Workers Planned: 2
> -> Unique (cost=18582710.39..18613960.39 rows=1 ...)
>-> Sort (cost=18582710.39..18593127.06 ...)
> Sort Key: t.unique1, ((SubPlan 1))
> ...
>
> which probably makes sense,
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
already is] pretty fragmented" is there a place for a simpler
improvement (adding a short explanation of this particular hazard) in
the meantime? I don't mean this specific v4 patch -- just in general
(since the patch can be revised of course).
Thanks,
James Coleman
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&
ese states may leak depending upon when this
> >>> function gets called.
> >>> 3. Building features on top as James envisions will be easier.
In my view the fact that auto_explain is itself not part of core is a
mistake, and I know there are more prominent hackers than myself who
hold that view.
While that decision as regards auto_explain has long since been made
(and there would be work to undo it), I don't believe that we should
repeat that choice here. I'm -10 on moving this into auto_explain.
However perhaps there is still an opportunity for moving some of the
auto_explain code into core so as to enable deduplicating the code.
Regards,
James Coleman
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
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
On Mon, Oct 2, 2023 at 2:55 PM Robert Haas wrote:
>
> On Sat, Sep 30, 2023 at 1:05 AM Peter Geoghegan wrote:
> > > This is why I discovered it: it says "indexes do not reference their
> > > page item identifiers", which is manifestly not true when talking
> > > about the root item, and in fact wo
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
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:
>
>
> QUERY PLAN
>-
> Limit
> -> GroupAggregate
>
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:
> > > >
101 - 200 of 565 matches
Mail list logo
