On Sat, Nov 13, 2010 at 7:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Nov 13, 2010 at 10:41 AM, Tom Lane 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
Robert Haas writes:
> On Sat, Nov 13, 2010 at 10:41 AM, Tom Lane 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. When the index does get
>> creat
On Sat, Nov 13, 2010 at 10:41 AM, Tom Lane wrote:
> Jon Nelson 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 = 'fo
On Sat, Nov 13, 2010 at 4:32 AM, Marc Mamin 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 information sour
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 po
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. T
Marti Raudsepp writes:
> On Mon, Nov 8, 2010 at 20:40, Tom Lane 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 that testing? You said you're
On Mon, Nov 8, 2010 at 20:40, Tom Lane 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 want. I thin
Jon Nelson 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 made.
The particular cas
On Sat, Nov 13, 2010 at 9:41 AM, Tom Lane wrote:
> Jon Nelson 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
On Sat, Nov 13, 2010 at 1:32 AM, Marc Mamin 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 information sour
Jon Nelson 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 foo_b_idx on foo (b);
> [
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
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 A
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 f
15 matches
Mail list logo
