Quick question if you guys happen to have the answ...
# announcements
r
Quick question if you guys happen to have the answer already but for the Postgres destination, do you truncate the table for full refreshes or drop it and recreate it? Wondering if I can modify the table's schema to have an index and have it persist.
1
j
It’s a truncate
This happens in
PostgresDestination
->
AbstractJdbcDestination
->
JdbcBufferedConsumerFactory:141
keanu thanks 1
r
Thanks a bunch, J-man.
c
On the final normalized table it s handled by dbt, i'm not so sure what s happening there...
👍 2
j
Oh good point. Are you actually using normalization for this Roshan?
r
Ah, I am. That's a good point.
Looks like
dbt
bashes the table and recreates it each time. Is there a thing I can do to retain an index on the finished result? Or even to just re-index each time? It's O(n²) to do that each time it syncs but I'll just slow down the sync. Alternatively, I could drop the sync to once a day and just also run
CREATE INDEX
once a day but that's solidly in megahax territory.
j
Once we have better DBT integration you would be able to set up a post hook: see https://github.com/fishtown-analytics/dbt/issues/804#issuecomment-398868392
That would allow you to do the expensive re-index.
We also have a project on our backlog to do more incremental dbt stuff, and I’m not sure if any of those changes will impact the table bashing. Chris might know?
r
Great, good stuff. I'll slow this sync and re-index periodically for now.
👍 1
Actually, this makes incremental copies not very useful to me at all. A full-table re-index is very slow. I will implement this sync myself manually.
j
That’s unfortunate. We basically have to wait for incremental DBT support for this.
👍 1
I’m honestly surprised this hasn’t been raised as a concern before.