The comparison would be
a if then else end if .. about 8 of them 2013-> and a static insert into
v's
making a dynamic string and using execute, my presumption would be the
execute would be expensive verses a INSERT command
A
On 1 August 2017 at 07:04, Scott Marlowe wrote:
> On Sun, Jul 30, 2
On Sun, Jul 30, 2017 at 7:13 PM, Alex Samad wrote:
> How expensive is dynamic over static. I'm looking at storing yearly now, so
> I figure if my if then clause has the latest year at the top it should be
> very quick.
Assuming you're not doing anything particularly crazy it's minimal.
But what
How expensive is dynamic over static. I'm looking at storing yearly now,
so I figure if my if then clause has the latest year at the top it should
be very quick.
On 31 July 2017 at 11:07, Justin Pryzby wrote:
> On Mon, Jul 31, 2017 at 10:25:54AM +1000, Alex Samad wrote:
> > I note that you l
On Mon, Jul 31, 2017 at 10:25:54AM +1000, Alex Samad wrote:
> I note that you link to P10 and I am currently looking at 9.6. The changes
> do look nice for partitioning for p10.
Yes sorry, pg10 is beta - avoid using it except for testing purposes.
> I will add currently we don't delete anything,
Hi
I note that you link to P10 and I am currently looking at 9.6. The changes
do look nice for partitioning for p10.
Interesting your suggest that the MM parition isn't that bad.
I will add currently we don't delete anything, we will keep adding to it.
Also I am thinking my insert trigger
On Mon, Jul 31, 2017 at 09:15:29AM +1000, Alex Samad wrote:
> Hi
>
> I was about to partition a large (?) approx 3T of data 2B rows into
> partition tables but broken up into MM ...
>
> Now I have been reading about limiting the number of partitions otherwise
> it could slow down the parser.
Hi
I was about to partition a large (?) approx 3T of data 2B rows into
partition tables but broken up into MM ...
Now I have been reading about limiting the number of partitions otherwise
it could slow down the parser.
My reasoning for limiting to MM was that most of the request would be
On Jun 28, 2009, at 11:45 AM, Whit Armstrong wrote:
Thanks, Tom.
Let me give a little more detail on my actual data rather than the
simple example I sent.
I have a 60GB table of loan balances, which I've partitioned into 26
tables.
The loan id's are a sequence of 6 characters, so the part
Thanks, Tom.
Let me give a little more detail on my actual data rather than the
simple example I sent.
I have a 60GB table of loan balances, which I've partitioned into 26 tables.
The loan id's are a sequence of 6 characters, so the partitioning rule
I've used is the first character of the loan
Whit Armstrong writes:
> I have a simple example copied from the 8.3 manual on partitioning
> (http://www.postgresql.org/docs/8.3/interactive/ddl-partitioning.html).
> My question is, if you create a serial type in the parent table which
> is meant to be the primary key across all the partitions,
I have a simple example copied from the 8.3 manual on partitioning
(http://www.postgresql.org/docs/8.3/interactive/ddl-partitioning.html).
My question is, if you create a serial type in the parent table which
is meant to be the primary key across all the partitions, how does one
guarantee uniquene
Hi All!
I have a table - transaction pool - with a lot of rows, but I use only
data for the latest month, or current year in my computations.
How can I split data to partitions like that if I can't use CHECK
constraints with non constant objects like, extract('month' from
CURRENT_DATE), extract('y
12 matches
Mail list logo
