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
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
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,
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
with the
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.
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 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
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
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:
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 the
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 are
11 matches
Mail list logo
