joeharris76

5 ms·

1.
by joeharris76 4y ago
1) create a table (and then query it) - seems very common 2) merge more into it (and then query it) - also seems very common 3) delete (a tiny bit) from it (and then query it) - also seems very common 4) delete (a little more) from
2.
by joeharris76 5y ago
> While performing the benchmarks, we noticed that the Snowflake pre-baked TPC-DS dataset had been recreated two days after our benchmark results were announced. An important part of the official benchmark is to verify the creation of th
3.
by joeharris76 7y ago
Yes, we did. https://docs.aws.amazon.com/redshift/latest/dg/stored-proced...
4.
by joeharris76 8y ago
Nice answer.
5.
by joeharris76 8y ago
Recommend checking who the account emails are configured to be sent to. Often they go to a finance person who may not understand the importance of some communications such as this.
6.
by joeharris76 9y ago
Redshift offers hard disk based nodes with huge amounts of storage at low cost for precisely the use case you mention. The performance of these is actually very good, especially with a little effort applied to choosing sort keys and dist ke
7.
by joeharris76 11y ago
We're very interested in trying AWS' new Database Migration Service to see if it provides a nice, automated way to get a mirror of the source into Redshift. https://aws.amazon.com/dms/
8.
by joeharris76 11y ago
I do have experience with ETL tools. The dirty secret of ETL tools is that they are slow in the best case. In the worst case extremely, head meltingly, how-could-it-possibly-take-that-long slow. Before MPP and columnar DBs (Vertica, Greenpl
9.
by joeharris76 11y ago
We've struggled with the same issues. We also keep a "base" schema in Redshift as a close mirror to source systems (tweaked a little for distribution keys). In our case we control the extracts but schema changes have to be ma