Gregory Stark wrote:
> "Bruce Momjian" <bruce@momjian.us> writes:
>
> > As stated in later email, I think we should focus on the xid idea
> > because it is more flexible.
>
> Sorry if I was unclear. I agree, my comment and questions are all predicated
> on the assumption that we would go with xids.
OK, replies below.
> > Gregory Stark wrote:
> >>
> >> "Bruce Momjian" <bruce@momjian.us> writes:
> >>
> >> > We also add a boolean to pg_class to indicate no new HOT chains should be
> >> > created and set that to false once the new index is created.
> >>
> >> Since we have all the index info in the relcache we could just skim through
> >> all the indexes when we build the relcache and decide then whether we're
> >> allowed to do HOT updates. That avoids problems if we crash while HOT updates
> >> are disabled.
Uh, with xid, we don't disable HOT updates at all --- we just control,
via xids, which indexes are part of which HOT update chain.
> >> I think we need to think harder about exactly what test we would perform
> >> against this xid to determine the two relevant tests,
> >>
> >> a) whether to prohibit HOT updates (because the index is "too new")
Never.
> >> b) whether to ignore HOT update chains when we use the index (because it's
> >> "too new" and any HOT update chains predate it).
We have to look at the xmax of the HOT chain head and compare that to
the index xid.
> >> I fear it may imply that we have to keep performing cold updates until the
> >> first vacuum after the xid expires.
Yes, effectively, that is true, because once we have the new index in
place, we can't reuse the old HOT chains --- we need VACUUM at some
point, but new HOT chains can be created.
Actually, since we have a _write_ lock on the table, there are no table
changes during index creation, so we only need to worry about changes
after the index is created.
After the index is created, old HOT chains have to be cleaned up via
VACUUM because we have the new index pointing into the HOT chain.
Existing transactions can't create new HOT chains because they would
have to insert into the new index (because of their xid), so they might
as well not use HOT. New transactions can create new HOT chains because
their xid marks them as including the new index in the index group.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
