Hello,
Just a short though:
Is it imaginable to compare the prognoses of the plans with the actual
results
and somehow log the worst cases ?
a) to help the DBA locate bad statistics and queries
b) as additional information source for the planner
This could possibly affect parameters of your
I was doing some testing with temporary tables using this sql:
begin;
select pg_sleep(30);
create temporary TABLE foo (a int, b int, c int, d text);
insert into foo SELECT (x%1000) AS a,(x%1001) AS b, (x % 650) as c, ''
as d FROM generate_series( 1, 100 ) AS x;
-- create temporary TABLE foo
Yes.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Jon Nelson jnelson+pg...@jamponi.net writes:
OK. This is a highly distilled example that shows the behavior.
BEGIN;
CREATE TEMPORARY TABLE foo AS SELECT x AS A, chr(x % 75 + 32) AS b,
''::text AS c from generate_series(1,500) AS x;
UPDATE foo SET c = 'foo' WHERE b = 'A' ;
CREATE INDEX
On Sat, Nov 13, 2010 at 1:32 AM, Marc Mamin m.ma...@intershop.de wrote:
Hello,
Just a short though:
Is it imaginable to compare the prognoses of the plans with the actual
results
and somehow log the worst cases ?
a) to help the DBA locate bad statistics and queries
b) as additional
On Sat, Nov 13, 2010 at 9:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Jon Nelson jnelson+pg...@jamponi.net writes:
OK. This is a highly distilled example that shows the behavior.
BEGIN;
CREATE TEMPORARY TABLE foo AS SELECT x AS A, chr(x % 75 + 32) AS b,
''::text AS c from
Jon Nelson jnelson+pg...@jamponi.net writes:
What would the effect be of patching postgresql to allow indexes to
see and follow the HOT chains during index creation?
It would break things. We did a *lot* of thinking about this when
HOT was implemented; there are not simple improvements to be
On Mon, Nov 8, 2010 at 20:40, Tom Lane t...@sss.pgh.pa.us wrote:
The latter choice is the one that requires testing to prove that it is the
proper and preferred default from the performance and data reliability POV.
And, in fact, the game plan is to do that testing and see which default
we
Marti Raudsepp ma...@juffo.org writes:
On Mon, Nov 8, 2010 at 20:40, Tom Lane t...@sss.pgh.pa.us wrote:
And, in fact, the game plan is to do that testing and see which default
we want. Â I think it's premature to argue further about this until we
have some test results.
Who will be doing
Craig Ringer wrote:
It sounds like you're describing Oracle-style MVCC, using redo logs.
http://blogs.sybase.com/database/2009/04/mvcc-dispelling-some-oracle-fudunderstanding-the-cost/
Craig, this is an interesting blog page, making some valid points about
the multiversioning vs. locking.
On 11/14/2010 02:38 AM, Mladen Gogala wrote:
Craig Ringer wrote:
It sounds like you're describing Oracle-style MVCC, using redo logs.
http://blogs.sybase.com/database/2009/04/mvcc-dispelling-some-oracle-fudunderstanding-the-cost/
Craig, this is an interesting blog page, making some valid
On Sat, Nov 13, 2010 at 4:32 AM, Marc Mamin m.ma...@intershop.de wrote:
Hello,
Just a short though:
Is it imaginable to compare the prognoses of the plans with the actual
results
and somehow log the worst cases ?
a) to help the DBA locate bad statistics and queries
b) as additional
On Sat, Nov 13, 2010 at 10:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Jon Nelson jnelson+pg...@jamponi.net writes:
OK. This is a highly distilled example that shows the behavior.
BEGIN;
CREATE TEMPORARY TABLE foo AS SELECT x AS A, chr(x % 75 + 32) AS b,
''::text AS c from
Robert Haas robertmh...@gmail.com writes:
On Sat, Nov 13, 2010 at 10:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
OK, this is an artifact of the HOT update optimization. Before
creating the index, you did updates on the table that would have been
executed differently if the index had existed.
On Sat, Nov 13, 2010 at 7:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Nov 13, 2010 at 10:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
OK, this is an artifact of the HOT update optimization. Before
creating the index, you did updates on the table
15 matches
Mail list logo
