Phil Endecott <[EMAIL PROTECTED]> writes:
> What would happen if I were to rollback at the end of the transaction,
> rather than committing (having made no changes)? Would that eliminate
> some or all of the catalog writes?
It would avoid fsync'ing the changes at commit time, but not really
red
Tom Lane wrote:
Phil Endecott <[EMAIL PROTECTED]> writes:
Does this make sense? I imagine that the temporary table is being added
to these tables and then removed again.
Yes, a temp table has the same catalog infrastructure as a regular
table, so creation and deletion of a temp table will cause
Phil Endecott <[EMAIL PROTECTED]> writes:
> Does this make sense? I imagine that the temporary table is being added
> to these tables and then removed again.
Yes, a temp table has the same catalog infrastructure as a regular
table, so creation and deletion of a temp table will cause some activit
Hi Tom,
I thought of a quicker way to investiage this than strace and did an ls
-lt in the data directory and looked up the tables that seem to change
on every transaction in pg_class. They are the catalog tables:
# ls -lt /var/lib/postgres/data/base/17142/
total 530108
-rw---1 postgres
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> One of the things on the TODO list is making the size of temp-table
> >> buffers user-configurable. (Temp table buffers are per-backend, they
> >> are not part of the shared buffer arena.) With a large temp-table
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> One of the things on the TODO list is making the size of temp-table
>> buffers user-configurable. (Temp table buffers are per-backend, they
>> are not part of the shared buffer arena.) With a large temp-table arena
>> we'd never need
Tom Lane wrote:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > I don't think temporary tables have any special rules regarding disk
> > writes, so I'd expect them ot get written out like everything else.
>
> They'll be written out from PG's internal buffers, but IIRC they will
> never be
Phil Endecott <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> In principle, therefore, the kernel could hold temp table data in its
>> own disk buffers and never write it out to disk until the file is
>> deleted. In practice, of course, the kernel doesn't know the data is
>> transient and will pr
Tom Lane wrote:
They [temporary tables]
> will be written out from PG's internal buffers, but IIRC they will
never be fsync'd, and they definitely aren't WAL-logged. (These
statements hold true in 8.0, but not sure how far back.)
In principle, therefore, the kernel could hold temp table data in it
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> I don't think temporary tables have any special rules regarding disk
> writes, so I'd expect them ot get written out like everything else.
They'll be written out from PG's internal buffers, but IIRC they will
never be fsync'd, and they definitel
I don't think temporary tables have any special rules regarding disk
writes, so I'd expect them ot get written out like everything else. The
database doesn't know you're going to delete them later.
Are the tables big?
On Thu, Dec 09, 2004 at 10:10:21PM +, Phil Endecott wrote:
> Dear All,
>
>
Dear All,
I sent a message last weekend asking about temporary tables being
written to disk but didn't get any replies. I'm sure there is someone
out there who knows something about this - please help! Here is the
question again:
Looking at vmstat output on my database server I have been supr
Dear Postgresql experts,
Looking at vmstat output on my database server I have been suprised to
see lots of disk writes going on while it is doing what should be
exclusively read-only transactions. I see almost no disk reads as the
database concerned is small enough to fit into the OS disk cach
13 matches
Mail list logo
