From: | Jasen Betts <jasen(at)xnet(dot)co(dot)nz> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Exclusion constraints with time expressions |
Date: | 2012-11-18 02:27:54 |
Message-ID: | k89h3a$4mh$1@reversiblemaps.ath.cx |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2012-11-06, Kevin Grittner <kgrittn(at)mail(dot)com> wrote:
>
> For TIMESTAMP WITHOUT TIME ZONE it couldn't be IMMUTABLE, because the
> result would be based on the time zone setting of the client
> connection; but adding a fixed interval to a UTC time to get a UTC
> time seems pretty immutable to me. That said, I'm not sure why STABLE
> wouldn't be good enough for such an optimization, if it were
> supported at all. I don't think we evaluate such expressions before
> developing the plan, though.
> If you run EXPLAIN ANALYZE on one of the queries involved, does it
> actually perform the scan of partitions which can be skipped at
> run-time, or does it show "never executed"?
In 8.4 I've seen scans of excluded partitions, fortunately they are index scans
which hit an index and find no rows on the first index page, so not too painful,
but there's still the locking overhead. I've learned to precompute the timestamptz
constants.
--
⚂⚃ 100% natural
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2012-11-18 02:46:46 | Re: Prepared Statement Name Truncation |
Previous Message | Jasen Betts | 2012-11-18 02:15:39 | Re: Exclusion constraints with time expressions |