"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Note that the 150 disk writes were for the CREATE and the DROP. Does
> that mean that we'd actually shave 84 of 150 writes?
It really shouldn't be the case that each system catalog tuple insertion
generates a separate write --- especially not for multiple insertions
into the same catalog, which we could expect to go into the same page or
few pages.
I think a large fraction of the writes you're measuring are coming from
the file create/unlink operations. It would certainly be important to
identify where the bulk of the cost *really* is before we start
expending effort on a solution.
> In suggesting this enhancement, my hope is that each session could
> check for a referenced table as a temporary in RAM before going to the
> system tables, in a manner vaguely similar to how space reserved by
> the temp_buffers GUC is used for temp table data.
This isn't very workable. For one thing, client-side operations such as
psql's \dt still need to see catalog entries for temp tables.
There's been some handwaving about keeping catalog entries for temp
tables in temp children of the main system catalogs, but it hasn't got
past the handwaving stage.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
