Robert Haas wrote:
> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01651.php
> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01983.php
>
> Josh's schedule was subsequently endorsed by Simon Riggs. So by my
> count we now have four votes for a 4-CF schedule and one for a 3-CF
>
Hi,
Peter Eisentraut writes:
> On tis, 2009-09-01 at 11:41 -0700, Josh Berkus wrote:
>> Opinions? Other objects which could take \e?
>
> All of them.
Well, I'd vote against \e table. Are you going to propose the CREATE
TABLE statement and have magics to produce the ALTER TABLE that would
resor
Hi, community
The case:
E.g. I need to write a function that should do updates of a table. In
the function I have to specify necessary columns I need to update as
arguments and write update of the columns with this arguments.
Everything is ok but the case when I need to skip some column in
update
On Tue, Sep 1, 2009 at 2:41 PM, Josh Berkus wrote:
> All,
>
> I've grown to adore the new \ef function editor.
>
> It doesn't seem like it would be that difficult to add a view editor as
> \ev. While editors would also be good for other objects, I don't think
> we can do \et or \er etc. because th
Hi all,
I have been trying to improve the performance of a C trigger only to notice
that the real bottleneck was the SPI execution of dynamic SQL statements. I
had been using SPI_exec(sql,0) until I tried SPI_exec(sql,1), since I am
targeting exactly one row each time for writing. This simple chan
Robert Haas wrote:
> I think this is a good illustration of the problems with
> decision-making in a community environment - given choices "3" and "4"
> most of the votes were somewhere between "3.25" and "3.75". I think,
> in general, that when people weigh in with clear opinions, we're
> pretty
Hello,
I wrote article about statistical function - when I tested Joe Celko's
method, I found some problems on not unique dataset:
on distinct dataset is rule so rows here is max(hi), then there is min(lo):
create table x1 (a integer);
insert into x1 select generate_series(1,10);
postgres=# se
On Wed, Sep 2, 2009 at 6:30 AM, Jaime
Casanova wrote:
> On Tue, Sep 1, 2009 at 9:55 PM, Robert Haas wrote:
>>
>> I'm a bit skeptical about partitioning as a solution, too. The
>> planner is just not clever enough with partitioned tables, yet.
Yeah, we need to fix that :)
I think we're already re
Peter Eisentraut wrote:
> On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote:
>> I wouldn't expect a packaged SuSE build to cater to all of that;
>> but it would be nice if they donated their init script to the
>> PostgreSQL project, so that those of us who have a reason to build
>> from so
Michael Nacos writes:
> I have been trying to improve the performance of a C trigger only to notice
> that the real bottleneck was the SPI execution of dynamic SQL statements. I
> had been using SPI_exec(sql,0) until I tried SPI_exec(sql,1), since I am
> targeting exactly one row each time for wri
Kevin Grittner wrote:
(2) We don't have the distribution's PostgreSQL package installed on
any of our machines, so I'd have to install it and risk breaking
something to even have a look at it.
Umm, no, you could either install the SRPM in a build directory, and
look there, or extrac
On Wed, Sep 2, 2009 at 3:13 PM, Kevin
Grittner wrote:
> # Copyright (c) 2006 SUSE Linux Products GmbH, Nuernberg, Germany.
> # All rights reserved.
>
> and that I would be violating that copyright by copying it to
> PostgreSQL. Am I wrong?
The above is just a statement of fact. It doesn't change
Gokulakannan Somasundaram writes:
> Well, i am at a very beginner level with Flex. I could see how flex works
> with it even if it is a ambiguity. Since it matches the rule with the
> maximum text and we don't allow a new line character in the rule, it works
> fine. Even in LL(1), it works fine,
Pavel Stehule writes:
> create table x1 (a integer);
> insert into x1
> values(2),(2),(3),(3),(4),(4),(5),(5),(6),(6),(6),(8),(9),(9),(10),(10);
> postgres=# select row_number() over (order by a), row_number() over
> (order by a desc) from x1;
> row_number | row_number
> +--
Greg Stark wrote:
> Kevin Grittner wrote:
>> # Copyright (c) 2006 SUSE Linux Products GmbH, Nuernberg, Germany.
>> # All rights reserved.
>>
>> and that I would be violating that copyright by copying it to
>> PostgreSQL. Am I wrong?
>
> The above is just a statement of fact. It doesn't change th
Hi Tom,
the only thing I can tell from EXPLAIN ANALYZE is how long the trigger took
Index Scan using some_pkey on sometable (cost=0.00..8.58 rows=1 width=253)
(actual time=0.046..0.050 rows=1 loops=1)
Index Cond: (pkey = 123456)
Trigger so_and_so_on_change: time=62.309 calls=1
running an equ
Kevin Grittner wrote:
I tracked down the license text. It includes these sections, which
leave me disinclined to copy the init script to the PostgreSQL contrib
directory:
The Software is a collective work of Novell.
You must acquire a license for each
installation of the Software and for
Itagaki Takahiro writes:
> WARNING: getopt(p) = ostgres
> FATAL: attempted change of parameter "port" ignored
> The first argument 'postgres' was interpreted as "-p ostgres" by getopt().
Ugh.
> We might need to re-initilaize variables for getopt() because we call
> process_postgres_sw
Andrew Dunstan wrote:
> Kevin Grittner wrote:
>> [SuSE Linux Enterprise Server license]
>> Novell reserves all rights not expressly granted to You. You may
>> not:
>> (2) transfer the Software or Your license rights under this
>> Agreement, in whole or in part.
> here is what's in what I got
Michael Nacos writes:
> the only thing I can tell from EXPLAIN ANALYZE is how long the trigger took
I was thinking of doing EXPLAIN ANALYZE via SPI_exec and seeing if you
got the same results as doing it manually.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Kevin Grittner wrote:
Andrew Dunstan wrote:
Kevin Grittner wrote:
[SuSE Linux Enterprise Server license]
Novell reserves all rights not expressly granted to You. You may
not:
(2) transfer the Software or Your license rights under this
Agreement, in whole or in part.
Hi everybody,
I am new PostgreSQL c function programmer. I'm trying to move ahead
a new "PostgreSQL routing library" (http://www.pgroute.org [for now, the
page in only in spanish]).
The point:
There is some way to keep objects in [persisten] memory and then refer
to these from c functions?
On Wed, 2009-09-02 at 10:21 -0400, Andrew Dunstan wrote:
>
> Umm, no, you could either install the SRPM in a build directory, and
> look there, or extract the script from the built RPM using rpm2cpio.
... actually I am maintaining SuSE spec and patches unofficially in RPM
repository:
https://pr
This is from within SPI_exec:
Nested Loop (cost=0.00..115947.18 rows=1952242 width=25) (actual
time=0.095..6425.291 rows=1952202 loops=1)
-> Index Scan using othertable_level_pkey on othertable
(cost=0.00..9.34 rows=1 width=25) (actual time=0.063..0.067 rows=1
loops=1)
Index Cond: ((le
On Sep 2, 2009, at 5:07 AM, Merlin Moncure wrote:
One reason I don't like this proposal is that postgresql does not
preserve the original 'create view' statement for editing. The
resulting sql that is given to you to edit is hopelessly mangled and I
think it's not good to encourage people to mo
David E. Wheeler wrote:
On Sep 2, 2009, at 5:07 AM, Merlin Moncure wrote:
One reason I don't like this proposal is that postgresql does not
preserve the original 'create view' statement for editing. The
resulting sql that is given to you to edit is hopelessly mangled and I
think it's not goo
Michael Nacos writes:
> The interesting thing is SQL_exec(sql,1) resulted in a different
> execution plan while the stray FROM was still in place.
Well, the stray FROM resulted in a useless cross-join, which would
have generated a lot of extra no-op row updates. I think what the
limit was doing
Andrew Dunstan writes:
> David E. Wheeler wrote:
>> Is there any reason that the CREATE VIEW output to pg_dump and,
>> presumably, \ev, couldn't be refactored to pretty-print the VIEW
>> declaration?
> Tom just said a day or two ago that he doesn't want pg_dump using any
> pretty printing, and
2009/9/2 Tom Lane :
> Pavel Stehule writes:
>> create table x1 (a integer);
>> insert into x1
>> values(2),(2),(3),(3),(4),(4),(5),(5),(6),(6),(6),(8),(9),(9),(10),(10);
>
>> postgres=# select row_number() over (order by a), row_number() over
>> (order by a desc) from x1;
>> row_number | row_num
> I'm getting this same error and wonder if Tom's fix is sufficient.
>
> IPPROTO_IPV6 is defined in wd2def.h IF _WIN32_WINNT >= 0x0501, but in
> pg_config_os.h _WIN32_WINNT is DEFINED as 0x0500 so
> IPPROTO_IPV6 is left
> undefined.
>
> Regards,
> Dave
>
> ---
> Unfortunatel
On Wed, Sep 2, 2009 at 19:34, Zeugswetter Andreas OSB
sIT wrote:
>> I'm getting this same error and wonder if Tom's fix is sufficient.
>>
>> IPPROTO_IPV6 is defined in wd2def.h IF _WIN32_WINNT >= 0x0501, but in
>> pg_config_os.h _WIN32_WINNT is DEFINED as 0x0500 so
>> IPPROTO_IPV6 is left
>> undefi
All,
> I'm having a hard time believing that VACUUM FULL really has any
> interesting use-case anymore.
Basically, for:
a) people who don't understand CLUSTER (easily fixed, simply create a
VACUUM FULL command which just does CLUSTER on the primary key)
b) people who are completely out of space
On Wed, 2009-09-02 at 10:41 -0700, Josh Berkus wrote:
> All,
>
>
> > I'm having a hard time believing that VACUUM FULL really has any
> > interesting use-case anymore.
>
> Basically, for:
> a) people who don't understand CLUSTER (easily fixed, simply create a
> VACUUM FULL command which just doe
On Wed, Sep 2, 2009 at 6:41 PM, Josh Berkus wrote:
> All,
>
>
>> I'm having a hard time believing that VACUUM FULL really has any
>> interesting use-case anymore.
>
> Basically, for:
> a) people who don't understand CLUSTER (easily fixed, simply create a
> VACUUM FULL command which just does CLUSTE
Greg Stark wrote:
> I don't think we want to cluster on the primary key. I think we just
> want to rewrite the table keeping the same physical ordering.
Well if that's what you want to do, couldn't you do something like?:
Lock the table.
Prop all indexes
Pass the heap with two pointers, one
Greg,
> I don't think we want to cluster on the primary key. I think we just
> want to rewrite the table keeping the same physical ordering.
Agreed.
> Well I've certainly seen people whose disks are more than 50% full.
> They tend to be the same people who want to compact their tables. I
> can't
On Wed, 2009-09-02 at 11:01 -0700, Josh Berkus wrote:
> Greg,
>
> > I don't think we want to cluster on the primary key. I think we just
> > want to rewrite the table keeping the same physical ordering.
>
> Agreed.
Are we sure about that? I would argue that the majority of users out
their (think
Andrew Dunstan writes:
> Kevin Grittner wrote:
>> So while OpenSuse seems a little less restrictive, it's still not
>> something we can copy into the PostgreSQL distribution, right?
> right.
Right. Your clean-room approach seems to have been the right thing.
regards, to
Greg Stark writes:
> On Wed, Sep 2, 2009 at 6:41 PM, Josh Berkus wrote:
>>> Perhaps we should go one version with a enable_legacy_full_vacuum
>>> which defaults to off. That would at least let us hear about use cases
>>> where people are unhappy with a replacement.
>>
>> I think we do need to do
On Wed, Sep 2, 2009 at 1:52 PM, Greg Stark wrote:
> We could deal with the admin scripts by making VACUUM FULL do the new
> behaviour. But I actually don't really like that. I wold prefer to
> break VACUUM FULL since anyone doing it routinely is probably
> mistaken.
So I have a script that goes an
On ons, 2009-09-02 at 09:13 -0500, Kevin Grittner wrote:
> We don't have the distribution's PostgreSQL package installed on
> any of our machines, so I'd have to install it and risk breaking
> something to even have a look at it.
Using Midnight Commander is the canonical way to peek inside uninsta
Robert Haas writes:
> So I have a script that goes and finds bloated tables and runs VACUUM
> FULL on them in the middle of the night if the bloat passes a certain
> threshold. The tables are small enough and the number of users is low
> enough that this doesn't cause any problems for me. I'm OK
On ons, 2009-09-02 at 19:24 +0200, Magnus Hagander wrote:
> On Sat, Aug 29, 2009 at 05:26, Tom Lane wrote:
> > pet...@postgresql.org (Peter Eisentraut) writes:
> >> Log Message:
> >> ---
> >> Derived files that are shipped in the distribution used to be built in the
> >> source directory ev
On Wed, Sep 2, 2009 at 6:57 PM, Kevin
Grittner wrote:
> Greg Stark wrote:
>
>> I don't think we want to cluster on the primary key. I think we just
>> want to rewrite the table keeping the same physical ordering.
>
> Well if that's what you want to do, couldn't you do something like?:
>
> Lock the
On ons, 2009-09-02 at 10:59 -0430, Christian Gonzalez wrote:
> Is posible to put
> persisten object in memory through postgresql c funtion?
Well, the PL/Perl and PL/Python languages do some variants of this using
their GD and SD variables. So it's surely possible in C as well.
Memory contexts ar
On Wed, Sep 2, 2009 at 2:31 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Wed, Sep 2, 2009 at 6:41 PM, Josh Berkus wrote:
Perhaps we should go one version with a enable_legacy_full_vacuum
which defaults to off. That would at least let us hear about use cases
where people are unhapp
Peter Eisentraut writes:
> On ons, 2009-09-02 at 19:24 +0200, Magnus Hagander wrote:
>> -kwlookup.c: % : ../../../backend/parser/%
>> +kwlookup.c: % : $(top_srcdir)/src/backend/parser/%
>> rm -f $@ && $(LN_S) $< .
> I think you can revert this if it helps you, although it's not clear to
> me why
On Wed, Sep 2, 2009 at 21:05, Tom Lane wrote:
> Peter Eisentraut writes:
>> On ons, 2009-09-02 at 19:24 +0200, Magnus Hagander wrote:
>>> -kwlookup.c: % : ../../../backend/parser/%
>>> +kwlookup.c: % : $(top_srcdir)/src/backend/parser/%
>>> rm -f $@ && $(LN_S) $< .
>
>> I think you can revert this
On Wed, Sep 2, 2009 at 2:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> So I have a script that goes and finds bloated tables and runs VACUUM
>> FULL on them in the middle of the night if the bloat passes a certain
>> threshold. The tables are small enough and the number of users is low
>> enoug
On Wed, Sep 2, 2009 at 11:29 AM, Christian
Gonzalez wrote:
> The point:
> There is some way to keep objects in [persisten] memory and then refer to
> these from c functions?. In the current version of pgRoute, each
> transaction load the graph in memory (using MemoryContext), this isn't a
> enterp
Peter Eisentraut wrote:
On ons, 2009-09-02 at 10:59 -0430, Christian Gonzalez wrote:
Is posible to put
persisten object in memory through postgresql c funtion?
Well, the PL/Perl and PL/Python languages do some variants of this using
their GD and SD variables. So it's surely possible
On Wed, Sep 2, 2009 at 8:10 PM, Robert Haas wrote:
> I confess to being a little fuzzy on the details of how this
> implementation (seq-scanning the source table for live tuples) is
> different/better from the current VACUUM FULL implementation. Can
> someone fill me in?
VACUUM FULL is a *lot* m
Ohh Thanks to all for your answers,
pgmemcache does exactly what I need, or how I need it, that is to
put my graph into a persistent memory for all transactions that have
permissions.
Thanks again,
Christian Gonzalez
El 02/09/09 14:47, Andrew Dunstan escribió:
Peter Eisentraut wrote:
Greg Stark writes:
> The backwards scan is awful for rotating media. The reading from the
> end and writing to the beginning is bad too, though hopefully the
> cache can help that.
Yeah. And all that pales in comparison to what happens in the indexes.
You have to insert index entries (retail) fo
Greg Stark writes:
> It scans pages *backwards* from the end (which does wonderful things
> on rotating media). Marks each live tuple it finds as "moved off",
> finds a new place for it (using the free space map I think?).
BTW, VACUUM FULL doesn't use the free space map --- that code predates
the
On Wed, Sep 2, 2009 at 4:57 AM, Heikki
Linnakangas wrote:
> That implies that we need a release manager. Electing one would be the
> first step. That's a lot of work and responsibility, with lots of
> potential for making people cross, so in practice I think as soon as
> someone steps up to the pl
On Wed, 2009-09-02 at 12:50 -0700, Selena Deckelmann wrote:
> On Wed, Sep 2, 2009 at 4:57 AM, Heikki
> Linnakangas wrote:
>
> > That implies that we need a release manager. Electing one would be the
> > first step. That's a lot of work and responsibility, with lots of
> > potential for making peop
Hello Kevin,
a technical comment about line 71 and following of your shell script:
# Check that we have one parameter: action
if [ $# -ne 1 ] ; then
if [ $# -lt 1 -o "$1" = "" ] ] ; then
log_failure_msg "$0: action not specified"
else
log_failure_msg "$0: too many parameters"
fi
l
Tom Lane escribió:
> Greg Stark writes:
> > It scans pages *backwards* from the end (which does wonderful things
> > on rotating media). Marks each live tuple it finds as "moved off",
> > finds a new place for it (using the free space map I think?).
>
> BTW, VACUUM FULL doesn't use the free space
Wolfgang Wilhelm wrote:
> if [ $# -lt 1 -o "$1" = "" ] ] ; then
Oops. Fixed patch attached. Thanks!
-Kevin
Index: contrib/start-scripts/linux-lsb
===
RCS file: contrib/start-scripts/linux-lsb
diff -N contrib/start-scripts/li
Joshua D. Drake escribió:
> On Wed, 2009-09-02 at 12:50 -0700, Selena Deckelmann wrote:
> > On Wed, Sep 2, 2009 at 4:57 AM, Heikki
> > Linnakangas wrote:
> >
> > > That implies that we need a release manager. Electing one would be the
> > > first step. That's a lot of work and responsibility, with
On Wed, Sep 2, 2009 at 3:30 PM, Greg Stark wrote:
> On Wed, Sep 2, 2009 at 8:10 PM, Robert Haas wrote:
>> I confess to being a little fuzzy on the details of how this
>> implementation (seq-scanning the source table for live tuples) is
>> different/better from the current VACUUM FULL implementation
On Wed, Sep 2, 2009 at 4:09 PM, Alvaro
Herrera wrote:
> Joshua D. Drake escribió:
>> On Wed, 2009-09-02 at 12:50 -0700, Selena Deckelmann wrote:
>> > On Wed, Sep 2, 2009 at 4:57 AM, Heikki
>> > Linnakangas wrote:
>> >
>> > > That implies that we need a release manager. Electing one would be the
>>
new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
archive one dir up, as usual (with index of all previous reports).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
On Wed, Sep 2, 2009 at 4:28 PM, Robert Haas wrote:
> On Wed, Sep 2, 2009 at 4:09 PM, Alvaro
> Herrera wrote:
>> Joshua D. Drake escribió:
>>> On Wed, 2009-09-02 at 12:50 -0700, Selena Deckelmann wrote:
>>> > On Wed, Sep 2, 2009 at 4:57 AM, Heikki
>>> > Linnakangas wrote:
>>> >
>>> > > That implies
Alvaro Herrera writes:
> Another weird consequence of this is that it bails out if it finds a
> tuple larger than it can fit in one of the earlier pages; if there's
> dead space to be compacted before that, it's not compacted.
I don't find a lot wrong with that. The code defines its purpose as
b
Grzegorz Jaskiewicz escribió:
> new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
>
> archive one dir up, as usual (with index of all previous reports).
What's with the "analyzer failures"? Did you submit bug reports about
them?
--
Alvaro Herrera
Tom Lane escribió:
> Alvaro Herrera writes:
> > Another weird consequence of this is that it bails out if it finds a
> > tuple larger than it can fit in one of the earlier pages; if there's
> > dead space to be compacted before that, it's not compacted.
>
> I don't find a lot wrong with that. Th
Alvaro Herrera writes:
> Tom Lane escribió:
>> I don't find a lot wrong with that. The code defines its purpose as
>> being to shorten the table file length. Once it hits a page that
>> can't be emptied, it cannot shorten the file any further, so why
>> shouldn't it stop?
> All that work, and i
On 2 Sep 2009, at 21:38, Alvaro Herrera wrote:
Grzegorz Jaskiewicz escribió:
new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
archive one dir up, as usual (with index of all previous reports).
What's with the "analyzer failures"? Did you submit bug reports about
Robert Haas writes:
> Previous emails from Tom seem to indicate that the mandate of -core is
> mostly to decide things like the timing of releases. If we gave that
> job to somebody else, would there be anything left for -core to do?
> If so, what? And on the flip side, it is precisely because o
On Wed, Sep 2, 2009 at 9:28 PM, Robert Haas wrote:
> Previous emails from Tom seem to indicate that the mandate of -core is
> mostly to decide things like the timing of releases.
That's not all we do.
> If we gave that
> job to somebody else, would there be anything left for -core to do?
> If so,
After week-lengthed investigation, now i 'm sure - my level of
qualification not enough for implementation task "GROUPING SETS".
I require documentation about the executor and the planner, i can't
understand scheme of work by source code.
Many code, many cases, but very little information "what is
Robert Haas writes:
> Anyway, I'm still curious about what'n'all -core actually does.
Not a lot. That's a feature, not a bug. Most project management
discussion happens on -hackers. If -hackers can't come to a decision
then core will try to resolve the deadlock (assuming we can agree ;-))
but
Robert, Heikki,
> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01651.php
> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01983.php
>
> Josh's schedule was subsequently endorsed by Simon Riggs. So by my
> count we now have four votes for a 4-CF schedule and one for a 3-CF
> s
Tom Lane escribió:
> Alvaro Herrera writes:
> > Tom Lane escribi�:
> >> I don't find a lot wrong with that. The code defines its purpose as
> >> being to shorten the table file length. Once it hits a page that
> >> can't be emptied, it cannot shorten the file any further, so why
> >> shouldn't i
Robert Haas wrote:
> On Tue, Sep 1, 2009 at 9:29 PM, Alvaro
> Herrera wrote:
>> Ron Mayer wrote:
>>> Greg Stark wrote:
That's what I want to believe. But picture if you have, say a
1-terabyte table which is 50% dead tuples and you don't have a spare
1-terabytes to rewrite the whole t
On Wed, Sep 2, 2009 at 5:55 PM, Josh Berkus wrote:
> Robert, Heikki,
>
>> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01651.php
>> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01983.php
>>
>> Josh's schedule was subsequently endorsed by Simon Riggs. So by my
>> count we now
I suppose the initdb invocation is needed as well:
/home/super/pg_stuff/pg_installations/pgsql.cvs_vanilla/bin/initdb -U super -D
/home/super/pg_stuff/pg_installations/pgsql.cvs_vanilla/data -E UTF8
--pwfile=/home/super/pg_stuff/.84devel
( that .84devel file does exist )
On Thu, September 3, 20
On Wed, Sep 2, 2009 at 11:55 PM, Ron Mayer wrote:
> Yet when I try it now, I'm having trouble making it work.
> Would you expect the ctid to be going down in the psql session
> shown below? I wonder why it isn't.
Even before HOT we preferentially tried to put updated tuples on the
same page they
Hackers,
Per discussions on two other threads on this list which have apparently
reached consensus, we will be going with the following schedule:
CF1 7/15 to 8/14
Alpha1 by 8/20
CF2 9/15 to 10/14
Alpha2 by 10/20
CF3 11/15 to 12/14
Alpha3 by 11/20
CF4 1/15 to 2/14
Alpha4 by 2/2
On Sep 2, 2009, at 4:42 PM, Josh Berkus wrote:
CF3 11/15 to 12/14
Alpha3 by 11/20
12/20?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 2, 2009 at 8:45 PM, Tom Lane wrote:
> Greg Stark writes:
>> The backwards scan is awful for rotating media. The reading from the
>> end and writing to the beginning is bad too, though hopefully the
>> cache can help that.
>
> Yeah. And all that pales in comparison to what happens in t
While test building from CVS head on fedora 10 (also on fedora 6), I get:
./configure --prefix=/home/super/pg_stuff/pg_installations/pgsql.cvs_vanilla
--with-pgport=6542
--quiet --enable-depend --with-openssl --with-perl --with-libxml --with-libxslt
gcc (GCC) 4.3.2
compile OK, tests OK, insta
On Wed, Sep 2, 2009 at 7:42 PM, Josh Berkus wrote:
> Hackers,
>
> Per discussions on two other threads on this list which have apparently
> reached consensus, we will be going with the following schedule:
>
> CF1 7/15 to 8/14
> Alpha1 by 8/20
> CF2 9/15 to 10/14
> Alpha2 by 10/20
> CF3
"Erik Rijkers" writes:
> While test building from CVS head on fedora 10 (also on fedora 6), I get:
> initializing pg_authid ... ok
> setting password ... ok
> initdb: The password file was not generated. Please report this problem.
> initdb: removing data directory
> "/home/super/pg_stuff/pg_inst
Robert,
> I would like to propose an additional stipulation on CF4 - namely,
> that we will reject out of hand any large patches that were not
> submitted to CF3. For the sake of definiteness, let's say that a
> large patch is anything whether diffstat run against the unified diff
> shows lines a
I wrote:
> "Erik Rijkers" writes:
>> While test building from CVS head on fedora 10 (also on fedora 6), I get:
>> initializing pg_authid ... ok
>> setting password ... ok
>> initdb: The password file was not generated. Please report this problem.
>> initdb: removing data directory
>> "/home/super
Here is a patch to implement "Support triggers on columns" in our ToDo list.
The syntax is:
CREATE TRIGGER name
BEFORE UPDATE OF col1, col12, ...
ON tbl FOR EACH ROW EXECUTE PROCEDURE func();
I consulted the previous work following:
Column-level triggers (From: Greg Sabino
On Thu, Sep 03, 2009 at 10:52:09AM +0900, Itagaki Takahiro wrote:
> Here is a patch to implement "Support triggers on columns" in our ToDo list.
>
> The syntax is:
> CREATE TRIGGER name
> BEFORE UPDATE OF col1, col12, ...
> ON tbl FOR EACH ROW EXECUTE PROCEDURE func();
Kudos!
On Wed, Sep 2, 2009 at 9:31 PM, Josh Berkus wrote:
> Robert,
>
>> I would like to propose an additional stipulation on CF4 - namely,
>> that we will reject out of hand any large patches that were not
>> submitted to CF3. For the sake of definiteness, let's say that a
>> large patch is anything whe
On Wed, Sep 2, 2009 at 9:52 PM, Itagaki
Takahiro wrote:
> Here is a patch to implement "Support triggers on columns" in our ToDo list.
>
> The syntax is:
> CREATE TRIGGER name
> BEFORE UPDATE OF col1, col12, ...
> ON tbl FOR EACH ROW EXECUTE PROCEDURE func();
>
> I consulted the pr
Robert,
> A. Update the status of patches on the wiki (because the patch authors
> and reviewers often didn't).
> B. Poke reviewers or patch authors who didn't respond in a timely
> fashion and/or move to "Returned with Feedback".
> C. Assign new patches to reviewers who requested them.
> D. Send
Robert Haas wrote:
> Wow, so I wouldn't have to do this any more?
>
> IF (TG_OP = 'UPDATE') THEN
> IF (OLD.foo IS NOT DISTINCT FROM NEW.foo AND OLD.bar IS NOT
> DISTINCT FROM NEW.bar
> AND OLD.baz IS NOT DISTINCT FROM NEW.baz) THEN
> RETURN NULL;
> END IF;
> END IF;
Su
On Wed, Sep 2, 2009 at 10:22 PM, Josh Berkus wrote:
> Robert,
>
>> A. Update the status of patches on the wiki (because the patch authors
>> and reviewers often didn't).
>> B. Poke reviewers or patch authors who didn't respond in a timely
>> fashion and/or move to "Returned with Feedback".
>> C. As
David Fetter wrote:
> > It's still arguable that we should add dependencies from column
> > triggers to referenced columns.
>
> +1 for adding the dependencies.
But how? First, I tried to use existing dependency mechanism:
ObjectAddress referenced;
referenced.classId = AttributeRelatio
Itagaki Takahiro wrote:
>
> David Fetter wrote:
>
> > > It's still arguable that we should add dependencies from column
> > > triggers to referenced columns.
> >
> > +1 for adding the dependencies.
>
> But how? First, I tried to use existing dependency mechanism:
>
> ObjectAddress referen
On Thu, Sep 03, 2009 at 01:19:25AM +0400, Олег Царев wrote:
> After week-lengthed investigation, now i 'm sure - my level of
> qualification not enough for implementation task "GROUPING SETS".
> I require documentation about the executor and the planner, i can't
> understand scheme of work by sourc
2009/9/2 Олег Царев :
> After week-lengthed investigation, now i 'm sure - my level of
> qualification not enough for implementation task "GROUPING SETS".
> I require documentation about the executor and the planner, i can't
> understand scheme of work by source code.
> Many code, many cases, but v
2009/9/3 Joshua Tolley :
> On Thu, Sep 03, 2009 at 01:19:25AM +0400, Олег Царев wrote:
>> After week-lengthed investigation, now i 'm sure - my level of
>> qualification not enough for implementation task "GROUPING SETS".
>> I require documentation about the executor and the planner, i can't
>> und
1 - 100 of 103 matches
Mail list logo