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 don't know how to do that
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 isn't sufficient. I removed the "In
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 don't know how to do that easily if the requirement is
> effectively "must only change one
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 isn't sufficient. I removed the "In summary" sentence because
> it simply doesn't follow from the
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 that adds a broader pruning
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 that adds a broader pruning section, but this at least
> brings the docs inline with reality
On Tue, Dec 5, 2023 at 10:51 AM James Coleman wrote:
>
> Hello,
>
> While working on my talk for PGConf.NYC next week I came across this
> bullet in the docs on heap only tuples:
>
> > Old versions of updated rows can be completely removed during normal
> > operation, including SELECTs, instead
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 it doesn't directly
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 it doesn't directly fit?
I think we should elide it. Maybe with a much larger
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 rather than a simple fixup for this
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 rather than a simple fixup for this one paragraph what we
> actually want is to split out the
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
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 would defeat the whole purpose of HOT
> > (at least in a
On Fri, Sep 29, 2023 at 6:27 PM James Coleman wrote:
> On Fri, Sep 29, 2023 at 4:06 PM Peter Geoghegan wrote:
> > I think that it's talking about what happens during opportunistic
> > pruning, in particular what happens to HOT chains. (Though pruning
> > does almost the same amount of useful
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 generally when a heap-only tuple is written
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 generally when a heap-only tuple is written -- which would
> include the first time a heap-only tuple is
On Fri, Sep 29, 2023 at 2:39 PM Peter Geoghegan wrote:
>
> On Fri, Sep 29, 2023 at 11:04 AM Peter Geoghegan wrote:
> > > But when a HOT update happens the entry in an (logically unchanged)
> > > index still points to the original heap tid, and that line item is
> > > updated with a pointer to
On Fri, Sep 29, 2023 at 11:04 AM Peter Geoghegan wrote:
> > But when a HOT update happens the entry in an (logically unchanged)
> > index still points to the original heap tid, and that line item is
> > updated with a pointer to the new line pointer in the same page.
>
> It's true that the
On Fri, Sep 29, 2023 at 10:39 AM James Coleman wrote:
> > Old versions of updated rows can be completely removed during normal
> > operation, including SELECTs, instead of requiring periodic vacuum
> > operations. (This is possible because indexes do not reference their page
> > item
On Fri, Sep 29, 2023 at 10:45 AM James Coleman wrote:
> Hello,
>
> While working on my talk for PGConf.NYC next week I came across this
> bullet in the docs on heap only tuples:
>
> > Old versions of updated rows can be completely removed during normal
> > operation, including SELECTs, instead
Hello,
While working on my talk for PGConf.NYC next week I came across this
bullet in the docs on heap only tuples:
> Old versions of updated rows can be completely removed during normal
> operation, including SELECTs, instead of requiring periodic vacuum
> operations. (This is possible because
21 matches
Mail list logo
