On Thu, 2008-02-28 at 14:38 +0530, Pavan Deolasee wrote:
> I had this idea sometime back. Not sure if this has been discussed before
Check the archives for my post to hackers in Jan 2007 and subsequent
discussion. It's possible, just a little fiddly.
--
Simon Riggs
2ndQuadrant http://www.2
On Fri, Feb 29, 2008 at 9:15 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>
> We've heard that idea before, and it's just as bad as it was when
> proposed before. "Pre-frozen" tuples eliminate any possibility of
> tracking when a tuple was inserted; which is extremely important to know
> when you
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> In a typical scenario, user might create a table and load data in the
> table as part of a single transaction (e.g pg_restore). In this case,
> it would help if we create the tuples in the *frozen* state to avoid
> any wrap-around related issues with t
>>> On Thu, Feb 28, 2008 at 3:08 AM, in message
<[EMAIL PROTECTED]>, "Pavan Deolasee"
<[EMAIL PROTECTED]> wrote:
> I had this idea sometime back. Not sure if this has been discussed before
There was a thread discussing the problems you're looking to address:
http://archives.postgresql.org/pgs
ITAGAKI Takahiro wrote:
Without this, very large read-only tables would require one round of
complete freezing if there are lot of transactional activities in the other
parts
of the database. And when that happens, it would generate lots of unnecessary
IOs on these large tables.
To make things
Pavan Deolasee wrote:
On Thu, Feb 28, 2008 at 3:05 PM, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
If that works, then we might also want to set the visibility hint bits.
Oh yes. Especially because random time-scattered index scans on
the table can actually generate multiple writes of a page
On Thu, Feb 28, 2008 at 3:25 PM, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
>
>
> Sounds cool. I recommended users to do VACUUM FREEZE just after initial
> loading, but we can avoid it with your method.
>
Yeah, and the additional step of VACUUM FREEZE adds up to the restore
time.
>
> To make
On Thu, Feb 28, 2008 at 3:05 PM, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
>
> If that works, then we might also want to set the visibility hint bits.
Oh yes. Especially because random time-scattered index scans on
the table can actually generate multiple writes of a page of a
read-only table.
"Pavan Deolasee" <[EMAIL PROTECTED]> wrote:
> In a typical scenario, user might create a table and load data in the table as
> part of a single transaction (e.g pg_restore). In this case, it would help if
> we
> create the tuples in the *frozen* state to avoid any wrap-around related
> issues
>
Pavan Deolasee wrote:
In a typical scenario, user might create a table and load data in the
table as part of a single transaction (e.g pg_restore). In this case,
it would help if we create the tuples in the *frozen* state to avoid
any wrap-around related issues with the table. Without this, very
I had this idea sometime back. Not sure if this has been discussed before
In a typical scenario, user might create a table and load data in the table as
part of a single transaction (e.g pg_restore). In this case, it would help if we
create the tuples in the *frozen* state to avoid any wrap-around
11 matches
Mail list logo