Hi,
Simon Riggs wrote:
On Wed, 2008-01-09 at 18:04 +0100, Markus Schiltknecht wrote:
What do you think about letting the database system know the split point
vs it having to find optimal split points automatically?
For me, managing the table's files can be separate from the chunking
that allo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 9 Jan 2008 23:52:09 +0100
Gavin Sherry <[EMAIL PROTECTED]> wrote:
te restrictions.
> >
> > Hmm, well if you found declaring the partitions a problem with
> > constraint exclusion it's not going to be any easier using other
> > declarative appr
On Wed, Jan 09, 2008 at 08:51:30PM +, Simon Riggs wrote:
> > That's what I would have done if it was easier to do with constraint
> > exclusion
> > (did only date partitioning), as the reporting queries will always have
> > some
> > server (stats by services, each service being installed on
On Wed, 2008-01-09 at 21:29 +0100, Dimitri Fontaine wrote:
> Le Wednesday 09 January 2008 19:27:41 Simon Riggs, vous avez écrit :
> > The WHERE clause approach might easily allow more than 2 chunks and they
> > need not be logically contiguous. So the phrase split point doesn't
> > really fit beca
Hi,
Le Wednesday 09 January 2008 19:27:41 Simon Riggs, vous avez écrit :
> The WHERE clause approach might easily allow more than 2 chunks and they
> need not be logically contiguous. So the phrase split point doesn't
> really fit because it implies a one dimensional viewpoint, but I'm happy
> for
On Wed, 2008-01-09 at 18:04 +0100, Markus Schiltknecht wrote:
> > So not convinced of the need for named sections of tables yet. It all
> > seems like detail, rather than actually what we want for managing large
> > tables.
>
> What do you think about letting the database system know the split po
[EMAIL PROTECTED] (Markus Schiltknecht) writes:
> Simon Riggs wrote:
>> With that in mind, can I clarify what you're thinking, please?
>
> Sure, I can try to clarify:
>
>> 2) the things you've been discussing are essential requirements of
>> partitioning and we could never consider it complete unti
On Wed, 2008-01-09 at 17:30 +0100, Markus Schiltknecht wrote:
> Simon Riggs wrote:
> > With that in mind, can I clarify what you're thinking, please?
>
> Sure, I can try to clarify:
>
> > 2) the things you've been discussing are essential requirements of
> > partitioning and we could never consi
Hi,
Simon Riggs wrote:
When I delete all rows WHERE some_date < 'cut-off date' on a segment
boundary value that would delete all segments that met the criteria. The
following VACUUM will then return those segments to be read-write, where
they can then be refilled with new incoming data. The only
Hi,
Simon Riggs wrote:
With that in mind, can I clarify what you're thinking, please?
Sure, I can try to clarify:
2) the things you've been discussing are essential requirements of
partitioning and we could never consider it complete until they are also
included and we must therefore talk ab
On Wed, 2008-01-09 at 15:53 +, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> Perhaps a good analogy is indexes. Index names are themselves kind of
> redundant and people usually use names which encode up most of the information
> of the definition.
>
> But the reason you
On Wed, 2008-01-09 at 16:20 +0100, Markus Schiltknecht wrote:
> Simon Riggs wrote:
> >> I have to admit I always found it kludgy to have objects named
> >> invoices_2000_JAN and invoices_2000_FEB and so on. It's kind of an meta
> >> denormalization. But so is specifying where clauses repeatedly.
>
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Wed, 2008-01-09 at 02:25 +, Gregory Stark wrote:
>
>> Without naming the DBA would have to specify the same ranges every time he
>> wants to change the properties. He might do a "SET read_only WHERE created_on
>> < '2000-01-01'" one day then anoth
Simon Riggs wrote:
I have to admit I always found it kludgy to have objects named
invoices_2000_JAN and invoices_2000_FEB and so on. It's kind of an meta
denormalization. But so is specifying where clauses repeatedly.
The idea for using the WHERE clauses was to specifically avoid naming.
I un
On Wed, 2008-01-09 at 02:25 +, Gregory Stark wrote:
> "Markus Schiltknecht" <[EMAIL PROTECTED]> writes:
>
> > There are two very distinct ways to handle partitioning. For now, I'm
> > calling
> > them named and unnamed partitioning.
> The naming is precisely the useful part in that it is ho
"Markus Schiltknecht" <[EMAIL PROTECTED]> writes:
> There are two very distinct ways to handle partitioning. For now, I'm calling
> them named and unnamed partitioning.
I had most of a draft email written which I seem to have lost in a reboot. To
a large degree I was on the same line of thought
Hi,
IMO, the lengthy discussion about Segment Exclusion and Segment
Visibility Maps has long turned into a discussion about partitioning in
general. I'm thankful for all the new insights it has brought me and I
want to continue sharing my view on things. What's following is highly
theoretical
17 matches
Mail list logo
