>
> I have a table that is capturing what is, basically, time series data
Time series data usually is concerned with "recent" data, and has a
subsequent drop off date. This is ideal for partitioning by timestamp - not
only do your queries only need to hit a few of the total tables, but you
can si
On Sun, Feb 18, 2024 at 10:32 PM Darryl Green
wrote:
> 1) Is my attempt to improve performance of insert AND (as the number of
> sources goes up, as it has) querying which is invariably by id but it is
> easy to include "and src = x" in the majority of usage (the other common
> case is to query a
On Mon, 19 Feb 2024 at 22:07, Darryl Green wrote:
>
> On Mon, 19 Feb 2024 at 14:23, David Rowley wrote:
> >
> > On Mon, 19 Feb 2024 at 16:32, Darryl Green wrote:
> > > 2) It would be nice to be able to specify the id as pk on the table being
> > > partitioned (as it was in the non-partitioned d
On Monday, February 19, 2024, David G. Johnston
wrote:
> On Monday, February 19, 2024, Darryl Green wrote:
>
>>
>> > It may be possible to still have it work by doing a speculative record
>> > in the index for the target table then go and check all of the other
>> > indexes before marking the sp
On Monday, February 19, 2024, Darryl Green wrote:
>
> > It may be possible to still have it work by doing a speculative record
> > in the index for the target table then go and check all of the other
> > indexes before marking the speculative entry as valid.
>
> It is always valid - except in the
On Mon, 19 Feb 2024 at 17:31, Peter Eisentraut wrote:
>
> On 19.02.24 04:32, Darryl Green wrote:
> > I note that in Postgresql 16 identity column handling in partitioned
> > tables has been aligned to the view that the partitioned table as a
> > whole is a single relation (and so a unique identity
On Mon, 19 Feb 2024 at 14:23, David Rowley wrote:
>
> On Mon, 19 Feb 2024 at 16:32, Darryl Green wrote:
> > 2) It would be nice to be able to specify the id as pk on the table
being partitioned (as it was in the non-partitioned definition of the
table) once to document and enforce that the partit
>
> 1) Is my attempt to improve performance of insert AND (as the number of
> sources goes up, as it has) querying which is invariably by id but it is
> easy to include "and src = x" in the majority of usage (the other common
> case is to query across all sources, asking for a set is unusual) a
> r
On 19.02.24 04:32, Darryl Green wrote:
I note that in Postgresql 16 identity column handling in partitioned
tables has been aligned to the view that the partitioned table as a
whole is a single relation (and so a unique identity across partitions).
This makes sense.
The change that I think yo
On Mon, 19 Feb 2024 at 16:32, Darryl Green wrote:
> 2) It would be nice to be able to specify the id as pk on the table being
> partitioned (as it was in the non-partitioned definition of the table) once
> to document and enforce that the partitions simply inherit the id pk. This
> would seem o
On Sunday, February 18, 2024, Darryl Green wrote:
>
> I note that in Postgresql 16 identity column handling in partitioned
> tables has been aligned to the view that the partitioned table as a whole
> is a single relation (and so a unique identity across partitions). This
> makes sense.
>
Where
Hi,
I have a table that is capturing what is, basically, time series data. We
use identity column as primary key.
I'm considering the potential to partition it by the "source" of the time
series (100s .. 1000s of sources) as often (but not always) use of this
table is to get the time series for on
12 matches
Mail list logo