Jochem van Dieten wrote:
On 2/1/07, Chris Dunlop wrote:
In maillist.postgres.dev, you wrote:
Rather than writing in-place, perhaps the SET ARCHIVE would
create a on-disk copy of the table.
Just like CLUSTER does now: create an on-disk copy first and swap the
relfilenodes of the files and flush
Ühel kenal päeval, N, 2007-02-01 kell 12:31, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > A more radical variation of the "restricted-use archive table" approach
> > is storing all tuple visibility info in a separate file.
> > At first it seems to just add overhead, but for lo
Hannu Krosing <[EMAIL PROTECTED]> writes:
> A more radical variation of the "restricted-use archive table" approach
> is storing all tuple visibility info in a separate file.
> At first it seems to just add overhead, but for lots (most ? ) usecases
> the separately stored visibility should be highl
Ühel kenal päeval, N, 2007-02-01 kell 14:38, kirjutas Hannu Krosing:
> Ühel kenal päeval, N, 2007-02-01 kell 13:24, kirjutas Gavin Sherry:
>
> > A different approach discussed earlier involves greatly restricting the
> > way in which the table is used. This table could only be written to if an
> >
Ühel kenal päeval, N, 2007-02-01 kell 13:24, kirjutas Gavin Sherry:
> A different approach discussed earlier involves greatly restricting the
> way in which the table is used. This table could only be written to if an
> exclusive lock is held; on error or ABORT, the table is truncated.
>
> The pr
On Thu, 2007-02-01 at 15:03 +1100, Chris Dunlop wrote:
> > A different approach discussed earlier involves greatly
> > restricting the way in which the table is used. This table
> > could only be written to if an exclusive lock is held; on
> > error or ABORT, the table is truncated.
>
> You're ta
On 2/1/07, Chris Dunlop wrote:
In maillist.postgres.dev, you wrote:
On Thu, 1 Feb 2007, Chris Dunlop wrote:
The main idea is that, there might be space utilisation and
performance advantages if postgres had "hard" read-only
tables, i.e. tables which were guaranteed (by postgres) to
never have
G'day Gavin,
In maillist.postgres.dev, you wrote:
> On Thu, 1 Feb 2007, Chris Dunlop wrote:
>> The main idea is that, there might be space utilisation and
>> performance advantages if postgres had "hard" read-only
>> tables, i.e. tables which were guaranteed (by postgres) to
>> never have their d
On Thu, 1 Feb 2007, Chris Dunlop wrote:
> G'day hackers,
G'Day Chris,
> already - I couldn't find anything in the mail archives, but
> that doesn't mean it's not there...)
There has been a lot of discussion about this kind of thing over the
years.
> The main idea is that, there might be space
G'day hackers,
I had some hand-wavy thoughts about some potential gains for
postgres in the data archiving/warehousing area. I'm not able
to do any work myself on this, and don't actually have a
pressing need for it so I'm not "requesting" someone do it, but
I thought it might be worth discussing
10 matches
Mail list logo
