Pavel Stehule escribió:
But question?
about MVCC?
Is necessary to use MVCC on pg_statistic and some columns from pg_proc?
Right now, we use MVCC everywhere because we have no choice. But there
are some things that would be better off not using MVCC; and indeed we
use a hack to make things
Greg Stark st...@enterprisedb.com wrote:
On Wed, Apr 29, 2009 at 7:57 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
But the scaling issues are there already with temp tables. This
actually makes it better, not worse, because the table can be
materialized once per session, not once
Greg Stark st...@enterprisedb.com writes:
I don't understand what you mean by a cost once per request. You only
have to create the temporary table on the first request. If you can't
tell which is the first request you only have to test whether it
exists which doesn't incur the consequences
On Tue, Apr 28, 2009 at 6:18 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
I was thinking in terms of throwing a warning in 8.4 and
implementing new behavior in 8.5.
If we're on that time frame with it, I guess it's not too early to
suggest what we
Greg Stark st...@enterprisedb.com wrote:
I've been thinking about Alvaro's idea of a separate smgr. If you
had a single pg_class entry for all sessions but the smgr knew to
store the actual data for it in a session-local file, either in a
session-specific tablespace or using the same
Greg Stark st...@enterprisedb.com wrote:
The whole point of having the schema declared in advance and then
having each procedure execution have access to a private (or
non-private) data store following that predefined schema is to avoid
having to execute any catalog changes with all the
On Wed, Apr 29, 2009 at 8:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This is all based on utterly-unproven assumptions about relative costs.
In particular, ISTM an additional network round trip or two associated
with testing for/creating a temp table could easily swamp any costs
associated
On Wed, Apr 29, 2009 at 7:57 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
But the scaling issues are there already with temp tables. This
actually makes it better, not worse, because the table can be
materialized once per session, not once per request.
Currently you have to issue
On Wed, Apr 29, 2009 at 01:34:19PM -0500, Andy Lester wrote:
I've got my git clone set up, a copy of GCC 4.4 (and other
compilers) at the ready, and am glad to help out on low-level scut
work. Anybody need anything done? splint? valgrind? Let me know.
Getting our Perl into shape would be
