On Fri, Jul 23, 2021 at 6:18 PM Tom Lane wrote:
> For btree indexes, you need a compatible notion of ordering, not only
> equality. That's really what's breaking my hypothetical case of a uint
> type. But as long as you implement operators that behave in a consistent
> fashion, whether they
Robert Haas writes:
> On Fri, Jul 23, 2021 at 5:47 PM Tom Lane wrote:
>> Hmm. Note that what this is checking for is same operator *class* not
>> same operator family (if it were doing the latter, Peter's case would
>> already work). I think it has to do that. Extending my previous
>> thought
On Fri, Jul 23, 2021 at 5:47 PM Tom Lane wrote:
> > You seemed to think my previous comments about comparing opfamilies
> > were hypothetical but I think we actually already have the
> > optimization Peter wants, and it just doesn't apply in this case for
> > lack of hacks.
>
> Hmm. Note that
Robert Haas writes:
> On Fri, Jul 23, 2021 at 2:07 PM Tom Lane wrote:
>> However, for the reasons I explained before, there are no general-purpose
>> cases where we can skip an index build on a type-changed column, so
>> there is no place to insert a similar hack for the timestamp[tz] case.
>
On Fri, Jul 23, 2021 at 2:07 PM Tom Lane wrote:
> Yes, I'm very well aware of that optimization. While it's certainly
> a hack, it fits within a design that isn't a hack, ie that there are
> common, well-defined cases where we can skip the table rewrite.
> However, for the reasons I explained
Peter Volk writes:
> thanks for the reply, I do understand that if a rewrite of the table
> needs to be avoided the binary image needs to be the same. Since PG 12
> there is an optimisation to avoid a rewrite of timestamp columns if
> they are converted to timestamp with tz and the target tz
Hi Tom,
thanks for the reply, I do understand that if a rewrite of the table
needs to be avoided the binary image needs to be the same. Since PG 12
there is an optimisation to avoid a rewrite of timestamp columns if
they are converted to timestamp with tz and the target tz offset is 0
I am
Robert Haas writes:
> I agree that it doesn't follow in general. I think it does in the case
> of timestamp and timestamptz, because I don't think either the choice
> of time zone or the fact that we're reckoning relative to a time zone
> can change which of two timestamps is considered earlier.
On Thu, Jul 22, 2021 at 11:29 AM Tom Lane wrote:
> As a thought experiment to prove that this is an issue, suppose that
> somebody invented an unsigned integer type, and made the cast from
> regular int4 follow the rules of a C cast, so that e.g. -1 becomes
> 2^32-1. Given that, an ALTER TYPE
Peter Volk writes:
> The problem is that I have a 60TB+ PG installation for which we need to
> modify all of the timestamp columns to timestamp with tz. The data in the
> columns are already in UTC so we can benefit from the patch listed above.
> Yet there are 2 cases in which we are having an
Hi,
this is a followup to a performance optimization during the conversion of a
column from a timestamp column to a "timestamp with tz" column. The initial
patch I am referring to is this one:
https://git.postgresql.org/gitweb/?p=postgresql.git=commitdiff=3c59263#patch4
and the previous
11 matches
Mail list logo
