Robert Haas writes:
> On Fri, Feb 19, 2010 at 11:33 PM, Tom Lane wrote:
>> We can also fetch that tuple's
>> relfilenode and pass it to the subplan, which we do by setting the $0
>> Param value before invoking the subplan.
> Are the same tuples in scope when evaluating the expression that sets
>
On Fri, Feb 19, 2010 at 11:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Feb 19, 2010 at 10:22 PM, Tom Lane wrote:
>>> Maybe, but the only reasonable place to put it would be within the
>>> (SubPlan N) reference,
>
>> I thought maybe it could do something like this:
>
>> SubPlan 1
>>
Robert Haas writes:
> On Fri, Feb 19, 2010 at 10:22 PM, Tom Lane wrote:
>> Maybe, but the only reasonable place to put it would be within the
>> (SubPlan N) reference,
> I thought maybe it could do something like this:
> SubPlan 1
> Parameters: $0 := b.oid
> -> Index Scan etc.
No, that's t
On Fri, Feb 19, 2010 at 11:05 PM, Robert Haas wrote:
> I don't think it's a stretch to say that I'm the one who is confused.
> I am under the (perhaps faulty) impression that when evaluating an
> expression there can only ever be three tuples in score: inner, outer,
s/score/scope.
> and scan. S
On Fri, Feb 19, 2010 at 10:22 PM, Tom Lane wrote:
> Robert Haas writes:
>> So I guess there are two issues here: (1) somehow I feel like we
>> should be telling the user what expression is being used to initialize
>> $0, $1, etc. when they are PARAM_EXEC parameters;
>
> Maybe, but the only reason
Robert Haas writes:
> So I guess there are two issues here: (1) somehow I feel like we
> should be telling the user what expression is being used to initialize
> $0, $1, etc. when they are PARAM_EXEC parameters;
Maybe, but the only reasonable place to put it would be within the
(SubPlan N) refere
Consider the following (rather lame) query:
rhaas=# explain (verbose) select (select oid from pg_class a where
a.oid = b.relfilenode) from pg_class b;
QUERY PLAN
-
Hi all,
I started setting up some halfway automated method of simulating hard crashes
and even while setting those up I found some pretty unsettling results...
Now its not unlikely that my testing is flawed but unfortunately I don't see
where right now (its 3am now and I have a 8h trainride behi
I wrote:
> However, even given that, it's odd that it prefers a plan with two sorts
> to a plan with one materialize. Poking around in costsize.c, I think
> that the reason for this is that the rescan cost of a sort is estimated
> at cpu_operator_cost per tuple, whereas rescanning a materialize no
Hi,
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> You expressed stability concerns coming from this patch.
>> Were these concerns because of locks timing out making
>> things fragile or because of general feelings about introducing
>> such a patch at the end of the release cycle? I was thin
On Fri, Feb 19, 2010 at 2:48 PM, Bruce Momjian wrote:
> Simon Riggs wrote:
>> On Wed, 2009-12-16 at 17:04 +0200, Peter Eisentraut wrote:
>> > On tis, 2009-12-15 at 17:19 +, Simon Riggs wrote:
>> > > running with log_checkpoints = on
>> > >
>> > > pg_ctl -D foo -m fast stop
>> > >
>> > > log sa
Tom Lane writes:
> Well, that isn't really going to help us in terms of what to do for 9.0.
> But the possibility that something like this might happen in future is
> one thing that makes me hesitant about extending CREATE LANGUAGE right
> now --- the more bells and whistles we put on it, the hard
Robert Haas writes:
> On Fri, Feb 19, 2010 at 2:09 PM, Tom Lane wrote:
>> The sticking point for me is still whether or not it's really a good
>> idea for pg_dump to be emitting CREATE OR REPLACE LANGUAGE. It does not
>> do that for any other object type. On the other hand, we've already
>> mad
On Fri, Feb 19, 2010 at 2:09 PM, Tom Lane wrote:
> David Fetter writes:
>> CREATE OR REPLACE LANGUAGE is an even bigger tar pit.
>> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00386.php
>
> The reason that patch got rejected was that it was implementing
> CREATE IF NOT EXISTS --- unde
Simon Riggs wrote:
> On Wed, 2009-12-16 at 17:04 +0200, Peter Eisentraut wrote:
> > On tis, 2009-12-15 at 17:19 +, Simon Riggs wrote:
> > > running with log_checkpoints = on
> > >
> > > pg_ctl -D foo -m fast stop
> > >
> > > log says
> > >
> > > LOG: received fast shutdown request
> > > LOG
Dimitri Fontaine writes:
> Not sure how helpful I'll be there, but I can't help placing the
> extension's proposal again.
> If we had extensions here, plpgsql would be a core maintained extension,
> made available by CREATE EXTENSION in the database (which initdb would
> do in templates), then ha
Tom Lane writes:
> Robert Haas writes:
>> I am still of the opinion that changing this was a bad idea for
>> exactly this reason. We could perhaps ameliorate this problem by
>> implementing CREATE OR REPLACE for languages and emitting that
>> instead; then the command in the dump would be a noop
David Fetter writes:
> CREATE OR REPLACE LANGUAGE is an even bigger tar pit.
> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00386.php
The reason that patch got rejected was that it was implementing
CREATE IF NOT EXISTS --- under a false name. The problem with
that is summarized here:
On Fri, Feb 19, 2010 at 1:44 PM, Tom Lane wrote:
> Did we have consensus on exactly what CREATE OR REPLACE LANGUAGE would
> do? Particularly in cases where the existing definition doesn't match
> pg_pltemplate?
I am of the opinion that any CREATE OR REPLACE command that completes
without error s
Robert Haas writes:
> On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane wrote:
>> ... Let me point out that
>> choosing to install plpgsql by default has already broken "--single"
>> restore of practically every pg_dump out there. Nobody batted an eye
>> about that. Why are we suddenly so concerned ab
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> It looks to me like the code in AlterSetting() will allow an ordinary
> >> user to blow away all settings for himself. Even those that are for
> >> SUSET variables and were presumably set for him by a superuser. Isn't
> >> this a
On Fri, Feb 19, 2010 at 01:34:46PM -0500, Robert Haas wrote:
> On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane wrote:
> > Takahiro Itagaki writes:
> >> David Fetter wrote:
> >>> support both pre-9.0 and post-9.0 PostgreSQLs. David Wheeler has
> >>> suggested that we special-case PL/pgsql for 9.0 and
On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane wrote:
> Takahiro Itagaki writes:
>> David Fetter wrote:
>>> support both pre-9.0 and post-9.0 PostgreSQLs. David Wheeler has
>>> suggested that we special-case PL/pgsql for 9.0 and greater, as it's
>>> in template0, where those tests are based.
>
>> +
Alvaro Herrera writes:
> Tom Lane wrote:
>> It looks to me like the code in AlterSetting() will allow an ordinary
>> user to blow away all settings for himself. Even those that are for
>> SUSET variables and were presumably set for him by a superuser. Isn't
>> this a security hole? I would expe
Tom Lane wrote:
> It looks to me like the code in AlterSetting() will allow an ordinary
> user to blow away all settings for himself. Even those that are for
> SUSET variables and were presumably set for him by a superuser. Isn't
> this a security hole? I would expect that an unprivileged user s
"Pierre C" writes:
> Yep, but it's a bit awkward and time-consuming, and not quite suited to
> ORM-generated requests since you got to generate all the plan names, when
> the SQL query itself would be the most convenient "unique
> identifier"...
The SHA1 proposal seems better to me.
Now you stil
Poking a bit deeper, it *does* think the plan with sorts is cheaper than
without. The mergejoin plan it really prefers is:
regression=# set enable_hashjoin TO 0;
SET
regression=# set enable_nestloop TO 0;
SET
regression=# explain ...
QUERY PLAN
On Feb 19, 2010, at 7:43 AM, David E. Wheeler wrote:
> Usually PGXS loads after setting all the environment variables, though I
> suspect that it wouldn't have any side effects to set regress_opts afterward.
> Also, there is no MAJORVERSION in earlier versions, so module authors would
> have to
Alpha4 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
Since I'll be away for the next few days, someone has to take it from
here: write announcement, move tarballs, send announcement.
--
Sent via pgsql-hackers mailing list (pg
On Fri, 19 Feb 2010, Tom Lane wrote:
Teodor Sigaev writes:
I found something strange with merge join. Let there are two table
Sorry, postgresql's version is 8.4 from today CVS
Can't reproduce it here, either in HEAD or 8.4. Sure you have a clean
build with no local modifications? The ou
On Feb 19, 2010, at 5:36 AM, Alvaro Herrera wrote:
>> Because it's a lot easier for `pg_regress --load-language=plpgsql` to mean
>> "ensure the language is installed" than it is for 3rd-party test suites to
>> detect what version they're being installed against.
>
> Why doesn't the Makefile run
On Thu, February 18, 2010 23:32, Andres Freund wrote:
> On Thursday 18 February 2010 22:25:35 Erik Rijkers wrote:
>> localhost:55432 => 8.4.2 instance (ssh tunnel)
>> /tmp:7575 => a 9.0devel standby
>>
>> time pg_dump -h localhost -p 55432 -t public.tab_jobs --clean --no-owner
>> --no-privileges m
Can't reproduce it here, either in HEAD or 8.4. Sure you have a clean
build with no local modifications? The outright-incorrect last plan
Sure, just checkout'ed sources. And it's reproduced on current HEAD right now.
More info:
postgresql.conf changes:
shared_buffers=128MB
temp_buffers=16MB
Teodor Sigaev writes:
>> I found something strange with merge join. Let there are two table
> Sorry, postgresql's version is 8.4 from today CVS
Can't reproduce it here, either in HEAD or 8.4. Sure you have a clean
build with no local modifications? The outright-incorrect last plan
you show see
On Thu, Feb 18, 2010 at 08:31:05PM -0600, David Christensen wrote:
>
> On Feb 18, 2010, at 2:19 PM, Pierre C wrote:
>
>>
>>> What about catching the error in the application and INSERT'ing into the
>>> current preprepare.relation table? The aim would be to do that in dev or
>>> in pre-prod environm
Teodor Sigaev wrote:
I found something strange with merge join. Let there are two table
Sorry, postgresql's version is 8.4 from today CVS
For what it's worth - 8.4.0 gives as expected.
aap=# explain UPDATE
t1
SET
f1 = t1.f1 || t2.f1
FROM
t2
WHERE
t2.f1 = t1.f1 AND
t2.f2 = t1.
David E. Wheeler wrote:
> On Feb 18, 2010, at 8:38 PM, Tom Lane wrote:
>
> >> The regression test in the core is targeting only its version,
> >> but some external projects have version-independent tests.
> >
> > I think it's more like "are under the fond illusion that their tests are
> > version
I found something strange with merge join. Let there are two table
Sorry, postgresql's version is 8.4 from today CVS
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hack
Hi!
I found something strange with merge join. Let there are two table
(http://www.sigaev.ru/misc/ex.sql.gz, 360Kb) t1 and t2, both without indexes.
Query is:
UPDATE
t1
SET
f1 = t1.f1 || t2.f1
FROM
t2
WHERE
t2.f1 = t1.f1 AND
t2.f2 = t1.f2 AND
t2.f3 = t1.f3 AND
t2.f4 =
On Thu, 2010-02-18 at 23:13 +0100, Erik Rijkers wrote:
> I ran this by accident
Good test, thanks for running it.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Thu, 2010-02-18 at 14:17 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Thu, 2010-02-18 at 14:23 +0200, Heikki Linnakangas wrote:
> >> A straightforward way to fix that is to WAL-log the real xid in the
> >> XLOG_BTREE_DELETE_PAGE records, instead of resetting it to
> >> FrozenTransactionI
Heikki Linnakangas wrote:
> Magnus Hagander wrote:
>> Well, it's going to make the process that reads the WAL cause actual
>> physical I/O... That'll take a chunk out of your total available I/O,
>> which is likely to push you to the limit of your I/O capacity much
>> quicker.
>
> Right, doesn't s
Joshua D. Drake wrote:
> On Fri, 2010-02-12 at 10:22 -0800, Josh Berkus wrote:
>> In addition to the changes you've proposed, one thing our docs could
>> really use is a single reference page which we could go to for all of
>> the .conf files. Right now, you need to rely on postgresql.org doc
>> s
2010/2/19 Tom Lane :
> Takahiro Itagaki writes:
>> David Fetter wrote:
>>> support both pre-9.0 and post-9.0 PostgreSQLs. David Wheeler has
>>> suggested that we special-case PL/pgsql for 9.0 and greater, as it's
>>> in template0, where those tests are based.
>
>> +1 for the CREATE LANGUAGE IF N
44 matches
Mail list logo
