From: | Ryan Booz <ryan(at)timescale(dot)com> |
---|---|
To: | Rob Sargent <robjsargent(at)gmail(dot)com> |
Cc: | Israel Brewster <ijbrewster(at)alaska(dot)edu>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Growth planning |
Date: | 2021-10-05 00:49:14 |
Message-ID: | CADyMnEzO6yk8mUYdNA4GFds3iqtWCVpfcJp3H9vvb4xV--+r0A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
As for clustering, unfortunately, it's a one-time operation in Postgres (as
far as I'm aware), so you'd have to "cluster" the index every time after an
insert or update of data. If it is partitioned, I presume it can be run on
the index of each partition table individually - but I'm not sure.
On Mon, Oct 4, 2021 at 6:05 PM Rob Sargent <robjsargent(at)gmail(dot)com> wrote:
> On 10/4/21 3:37 PM, Israel Brewster wrote:
>
> On Oct 4, 2021, at 1:21 PM, Rob Sargent <robjsargent(at)gmail(dot)com> wrote:
>
> My "strict" table per station suggestion was meant as an option to avoid
> the partitioning pain point entirely if it wasn't going to buy you
> anything. Namely querying more than one station's data.
>
>
> Ah, so in theory making “strict” tables for each would be easier than
> creating partitions for each? Something to consider for sure if so.
>
>
> In a write-once scenario such as this, would a "clustered index" on
> datetime be stable, performant? Seems a read-for-export could put the head
> down at time point A and just go?
>
> That’s beyond my level of DB admin knowledge, unfortunately :) I can
> certainly read up on it and give it a try though!
>
>
> I was hoping one of the smart people would chime in;)
>
From | Date | Subject | |
---|---|---|---|
Next Message | Brent Wood | 2021-10-05 03:36:09 | help implementing OGR Postgres foreign data wrapper |
Previous Message | Steve Midgley | 2021-10-04 23:34:27 | Re: Testing of a fast method to bulk insert a Pandas DataFrame into Postgres |