Thanks Dean, that's really helpful. Because my x axis values are actually
derived from 'extract(epoch from tstz_col)', it is simple for me to
subtract an offset.
Cheers,
Steve
On Sun, Mar 24, 2019 at 7:55 PM Dean Rasheed
wrote:
> On Sun, 24 Mar 2019 at 08:01, Steve Baldwin
> wrote:
> >
> > Th
Meant to send this to the list but hit the wrong button.
On Sun, Mar 24, 2019 at 9:45 AM Ron wrote:
> On 3/24/19 3:05 AM, Frank wrote:
> >
> >
> > On 2019-03-24 9:25 AM, Ron wrote:
> >> On 3/24/19 1:42 AM, Frank wrote:
> >>> Hi all
> >>>
> >>> As I understand it, a general rule of thumb is that
On 2019-03-24 10:05:02 +0200, Frank wrote:
>
>
> On 2019-03-24 9:25 AM, Ron wrote:
> > On 3/24/19 1:42 AM, Frank wrote:
> > > As I understand it, a general rule of thumb is that you should
> > > never create a physical column if the data could be derived from
> > > existing columns.
The main re
On 3/24/19 3:45 AM, Ron wrote:
[snip]
In every DBMS that I've used, the lside (left side) needs to be static
(not "a" static) instead of variable (like a function).
Thanks to Chris Travers for reminding me that the word is "immutable", not
"static".
--
Angular momentum makes the world go 'ro
On 2019-03-24 11:11 AM, Tony Shelver wrote:
Not the answer you are looking for, but...
I'd suggest trying to create a non-trivial set of dummy data to test your
assumptions before deciding on a route.
It's saved my (professional) life a few times over the years when dealing
with untested desi
Not the answer you are looking for, but...
I'd suggest trying to create a non-trivial set of dummy data to test your
assumptions before deciding on a route.
It's saved my (professional) life a few times over the years when dealing
with untested designs and new (to us) technology.
Some years ago w
On Sun, Mar 24, 2019 at 9:05 AM Frank wrote:
>
>
> On 2019-03-24 9:25 AM, Ron wrote:
> > On 3/24/19 1:42 AM, Frank wrote:
> >> Hi all
> >>
> >> As I understand it, a general rule of thumb is that you should never
> >> create a physical column if the data could be derived from existing
> >> colum
On Sun, 24 Mar 2019 at 08:01, Steve Baldwin wrote:
>
> Thanks Tom,
>
> I've tried this on 11.2 (OS X 10.14.3, installed locally) and 10.6 (AWS RDS)
> instances with identical results. The values you show are identical to those
> returned by Oracle so that's great but why am I seeing different r
On 3/24/19 3:05 AM, Frank wrote:
On 2019-03-24 9:25 AM, Ron wrote:
On 3/24/19 1:42 AM, Frank wrote:
Hi all
As I understand it, a general rule of thumb is that you should never
create a physical column if the data could be derived from existing
columns. A possible reason for breaking this
On 2019-03-24 9:25 AM, Ron wrote:
On 3/24/19 1:42 AM, Frank wrote:
Hi all
As I understand it, a general rule of thumb is that you should never
create a physical column if the data could be derived from existing
columns. A possible reason for breaking this rule is for performance
reasons.
Thanks Tom,
I've tried this on 11.2 (OS X 10.14.3, installed locally) and 10.6 (AWS
RDS) instances with identical results. The values you show are identical
to those returned by Oracle so that's great but why am I seeing different
results?
This is from my local install:
log=# select version();
On 3/24/19 1:42 AM, Frank wrote:
Hi all
As I understand it, a general rule of thumb is that you should never
create a physical column if the data could be derived from existing
columns. A possible reason for breaking this rule is for performance reasons.
I have a situation where I am consid
12 matches
Mail list logo
