Hi, sorry for my consecutive posting.
On Fri, Dec 5, 2008 at 4:00 PM, Fujii Masao [EMAIL PROTECTED] wrote:
Hello,
On Fri, Dec 5, 2008 at 12:09 PM, Fujii Masao [EMAIL PROTECTED] wrote:
I was expecting you to have walreceiver and startup share an end of WAL
address via shared memory, so that
On Thu, 4 Dec 2008, Zdenek Kotala wrote:
1) Keep relfileid of toast file same. It is important because toast pointer
contains relfileid. Currently script creates fake files with same number to
protect postgresql to create new relation with this refileid. It works but by
my opinion it is not
On Fri, 5 Dec 2008, Vladimir Sitnikov wrote:
Oracle's approach is to have the explain command stuff the results into a
table. That has advantages for tools, especially if you want to be able to
look at plans generated by other sessions.
I do not believe that workflow makes sense. I have never
Greg Smith [EMAIL PROTECTED] writes:
I'm sorry, I think I misunderstood the original idea, what you're talking
about makes a lot more sense now. You want to save the space of the dead
column by replacing it with NULL, not remove it from the table definition.
Not so much to save the space,
Kurt Harriman wrote:
Sometimes people would like to call C++ code in the PostgreSQL
backend environment... for example, in user-defined functions,
triggers, access methods. And there is sometimes a need for
C++ code to call back into PostgreSQL's C functions, such as
the SPI interface.
Have
A seriously substantial portion of the diff for this patch all is
supporting trivial renaming, like changing everything that uses:
- TypeName *typename = (TypeName *) cmd-def;
+ TypeName *typeName = (TypeName *) cmd-def;
Is that really necessary? After going through a few
Hi Greg,
Actually I did email this to the list with 4 separate diffs in
4 separate attached files. I don't know why it appears all
massed together at http://archives.postgresql.org/pgsql-hackers.
I'll try resubmitting them separately. The first diff consists
of just the renaming, which is
On Fri, 5 Dec 2008, Greg Smith wrote:
If it is needed, I'd suggest you'd get a warmer reception here submitting two
diffs, one that just did the renaming and a second that actually had the
functional bits in it.
You can just ignore this late night bit of idiocy, or mock me for it as
you see
(Re-sending just the first of four patches: c++reserved)
These patches are based on CVS head in which the latest commit was
user:petere
date:Thu Dec 04 17:51:28 2008 +
summary: Default values for function arguments
1. c++reserved
User-defined functions and
(Re-sending just the second of four patches: c++bookends)
These patches are based on CVS head in which the latest commit was
user:petere
date:Thu Dec 04 17:51:28 2008 +
summary: Default values for function arguments
2. c++bookends
C++ code can call C functions
(Re-sending just the third of four patches: c++configure)
These patches are based on CVS head in which the latest commit was
user:petere
date:Thu Dec 04 17:51:28 2008 +
summary: Default values for function arguments
3. c++configure
This patch adds C++ support to
(Re-sending just the fourth of four patches: c++exception)
These patches are based on CVS head in which the latest commit was
user:petere
date:Thu Dec 04 17:51:28 2008 +
summary: Default values for function arguments
4. c++exception
When C code calls C++ code,
On Fri, 5 Dec 2008, Kurt Harriman wrote:
Actually I did email this to the list with 4 separate diffs in
4 separate attached files. I don't know why it appears all
massed together at http://archives.postgresql.org/pgsql-hackers.
Thanks for being so attentive. Your e-mail was fine, the
On Friday 05 December 2008 03:55, Peter Eisentraut wrote:
Kurt Harriman wrote:
Sometimes people would like to call C++ code in the PostgreSQL
backend environment... for example, in user-defined functions,
triggers, access methods. And there is sometimes a need for
C++ code to call back
I updated the patch set of SE-PostgreSQL and related (r1280)
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1280.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1280.patch
[3/6]
On Fri, 2008-12-05 at 16:00 +0900, Fujii Masao wrote:
On Fri, Dec 5, 2008 at 12:09 PM, Fujii Masao [EMAIL PROTECTED] wrote:
I was expecting you to have walreceiver and startup share an end of WAL
address via shared memory, so that startup never tries to read past end.
That way we would be
On Fri, 2008-12-05 at 12:09 +0900, Fujii Masao wrote:
On Thu, Dec 4, 2008 at 6:29 PM, Simon Riggs [EMAIL PROTECTED] wrote:
The only sensible settings are
synchronous_commit = on, synchronous_replication = on
synchronous_commit = on, synchronous_replication = off
synchronous_commit =
Greg Smith [EMAIL PROTECTED] writes:
You can just ignore this late night bit of idiocy, or mock me for it as you
see
fit. Note to other reviewers: if your e-mail client is the sort that bunches
a series of text attachments all together, make sure to scroll completely past
the first patch
Hi Peter,
Have you considered writing a procedural language plugin for C++?
C++ can masquerade as C, so I don't think it needs a separate
plugin. Just tell PostgreSQL that your user-defined function
is C even though you secretly know it is C++.
This series of patches is meant to address some
Kurt Harriman [EMAIL PROTECTED] writes:
Hi Peter,
Have you considered writing a procedural language plugin for C++?
C++ can masquerade as C, so I don't think it needs a separate
plugin. Just tell PostgreSQL that your user-defined function
is C even though you secretly know it is C++.
Kurt Harriman wrote:
Have you considered writing a procedural language plugin for C++?
C++ can masquerade as C, so I don't think it needs a separate
plugin. Just tell PostgreSQL that your user-defined function
is C even though you secretly know it is C++.
FYI, we have received patches
Greg Smith wrote:
On Wed, 3 Dec 2008, Bruce Momjian wrote:
As the author of the original shell script, which was in
/contrib/pg_upgrade, I think the code has grown to the point where it
should be reimplemented in something like Perl.
Ah, there's the common ancestor I couldn't find.
On Thu, Dec 4, 2008 at 9:53 AM, Dmitry Koterov [EMAIL PROTECTED] wrote:
Hello.
I can successfully ALTER a NON-EMPTY table (ct) which ROWTYPE is used as a
column type for another table (dt):
CREATE TABLE ct (id INTEGER);
CREATE TABLE dt (id INTEGER, c ct);
INSERT INTO dt VALUES(1,
I would tend to think it's worth it myself.
I am unfortunately not familiar enough with the postgresql code base to
be comfortable to provide a patch. Can I submit this optimization
request to some sort of issue tracker or what should I do?
--
Sent via pgsql-hackers mailing list
Euler Taveira de Oliveira wrote:
Alvaro Herrera escreveu:
I've already modified your patch a bit ... please send your updated
patch so I can merge it into mine. However, my changes were also
relatively minor. Since Tom wants it to be entirely rewritten then
maybe merging minor fixes
Hi Kevin,
Yeah I see exactly the same problem on 8.3.5 too, although it seems
random - what seems to happen is that sometimes the contents of the
temporary table disappears. I've attached a test script which causes the
error *some* of the time, although it tends to occur more often just
Mark Cave-Ayland [EMAIL PROTECTED] writes:
So in other words, the contents of the temporary table has just disappeared :(
Uhm. That rather sucks. I was able to reproduce it too.
It seems to happen after I pause for a bit, and not when I run the script in
fast succession.
--
Gregory Stark
tmp [EMAIL PROTECTED] writes:
I would tend to think it's worth it myself.
I am unfortunately not familiar enough with the postgresql code base to be
comfortable to provide a patch. Can I submit this optimization request to some
sort of issue tracker or what should I do?
You could add it to
The main benefit is that you can track how EXPLAIN plans change over time.
It is not required to output plan *into* some table to be able track it over
time. If EXPLAIN returns a table, it is up to you to perform insert into
history select * from explain(...).
Workflow that does not make sense
Kurt Harriman [EMAIL PROTECTED] writes:
[ make the backend C++-compilable ]
This has been proposed before, and rejected before, and I don't believe
the arguments have changed in the least.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Devrim GÜNDÜZ wrote:
On Thu, 2008-12-04 at 18:38 +0100, Magnus Hagander wrote:
Do the RPM initscript by any chance pass something like '-A ident
sameuser' to initdb? If so, that's where the fix needs to go. Initdb
defaults to trust...
Good catch. So, AFAICS running initdb with
-A ident
One issue with packaged multiple-version installations (practiced by
Debian, Solaris, and soon Fedora?) is that the mo files (translation
files) should be in a fixed location like /usr/share/locale, which does
not allow PostgreSQL-version specific subdirectories.
The Debian packages solve
Greg Smith napsal(a):
On Thu, 4 Dec 2008, Zdenek Kotala wrote:
1) Keep relfileid of toast file same. It is important because toast
pointer contains relfileid. Currently script creates fake files with
same number to protect postgresql to create new relation with this
refileid. It works but by
Solaris currently stores messages into separate directories like
/usr/postgres/8.3/share/locale which solves multiversion problem, but it brings
another problem, because gettext on solaris needs extra directory infrastructure.
I think debians patch is good approach.
Zdenek
Gregory Stark [EMAIL PROTECTED] writes:
Well one thing that might be useful for a c++ procedural language would be
catching C++ exceptions and translating them into ereports which could then be
caught in Postgres.
That's actually what I thought you had done but I just reread your mail and
Peter Eisentraut wrote:
http://bazaar.launchpad.net/~pitti/postgresql/debian-8.3/annotate/127?file_id=03gettextdomains.pat-20060925215343-vp3e1xxgtg0tzea6-45
Solaris packaging is currently looking for a solution, and the Fedora
initiative might as well? So I figured we could adopt
Peter Eisentraut wrote:
FYI, we have received patches morally equivalent to yours many times
over the years, and they have all been rejected. You might want to
review the archives about that.
Hi Peter,
I went back as far as 2005 in the archives, and found only this thread
covering similar
On Fri, 2008-12-05 at 16:20 +0200, Peter Eisentraut wrote:
Solaris packaging is currently looking for a solution, and the Fedora
initiative might as well? So I figured we could adopt something like
the above patch as a built-in solution, as a build option or even by
default.
Comments?
Kevin Grittner [EMAIL PROTECTED] writes:
One more data point to try to help.
While the jump from a default_statistics_target from 10 to 1000
resulted in a plan time increase for a common query from 50 ms to 310
ms, at a target of 50 the plan time was 53 ms. Analyze time was 7.2
minutes
Gregory Stark wrote:
Uhm. That rather sucks. I was able to reproduce it too.
It seems to happen after I pause for a bit, and not when I run the script in
fast succession.
Thanks for the verification Greg. I'm wondering if the GiST part is a
red herring, and in fact it is related to some
Gregory Stark [EMAIL PROTECTED] wrote:
Incidentally this timing is with the 75kB toasted arrays in shared
buffers
because the table has just been analyzed. If it was on a busy system
then
just
planning the query could involve 75kB of I/O which is what I believe
was
happening to me way
Tom Lane wrote:
Kurt Harriman [EMAIL PROTECTED] writes:
[ make the backend C++-compilable ]
This has been proposed before, and rejected before, and I don't believe
the arguments have changed in the least.
Hi Tom,
Of the series of four patches, the first two (c++reserved and c++bookends)
Robert W. Burgholzer [EMAIL PROTECTED] writes:
FWIW,
I have experienced some oddities in performing SELECT statements after
restarting on an 8.2 system, whereby I occasionally would get a ton of
duplicate records when I would do a select statement (my assumption is that
they are deleted
Gregory Stark [EMAIL PROTECTED] wrote:
Incidentally, here's a graph of the explain time for that plan. It
looks
pretty linear to me
Except for that sweet spot between 50 and 100.
Any idea what's up with that?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Peter Eisentraut wrote:
The Debian packages solve this by appending a version number to the mo
files themselves, as can be seen in this patch:
http://bazaar.launchpad.net/~pitti/postgresql/debian-8.3/annotate/127?file_id=03gettextdomains.pat-20060925215343-vp3e1xxgtg0tzea6-45
Of course, as
Looks like Robert accidentally answered my question about what version his
results were from off-list. Here's his update:
---
Unfortunately it was 8.2.9, as I realized halfway into the run. Here are
the results from a CVS HEAD checkout last night.
*** Query planning times
q1 (the complex
All,
I'm thinking that default_statistics_target is disputable enough that we
want to move discussion of it to pgsql-performance, and for version 0.1 of
the tuning wizard, exclude it.
--
--Josh
Josh Berkus
PostgreSQL
San Francisco
--
Sent via pgsql-hackers mailing list
Robert,
On Fri, Dec 5, 2008 at 7:24 PM, Greg Smith [EMAIL PROTECTED] wrote:
comparing to 8.2.9 results:
- q1 was 32% slower with dst = 10, 33% slower with dst = 1000
- other queries were 19% slower with dst = 10, 25% slower with dst = 1000
You mean that HEAD is slower than 8.2.9 or I don't
Hi Alvaro,
Alvaro Herrera [2008-12-05 14:06 -0300]:
Of course, as is it's not acceptable; the version number should be
obtained from PG_VERSION or some such.
Right, it has actually been on my long-term wishlist to replace that
patch with an autoconfiscated one with a non-hardcoded version
On Fri, Dec 5, 2008 at 7:24 PM, Greg Smith [EMAIL PROTECTED] wrote:
comparing to 8.2.9 results:
- q1 was 32% slower with dst = 10, 33% slower with dst = 1000
- other queries were 19% slower with dst = 10, 25% slower with dst = 1000
You mean that HEAD is slower than 8.2.9 or I don't
On Fri, Dec 5, 2008 at 8:11 PM, Robert Haas [EMAIL PROTECTED] wrote:
Correct. As compared with 8.2.9, ANALYZE was substantially faster,
but query planning was significantly slower.
Thanks also to Greg for reposting my emails. I didn't even realize I
hadn't sent them to the list.
Any chance
Thanks also to Greg for reposting my emails. I didn't even realize I
hadn't sent them to the list.
Any chance you could do the same test with a 8.3? It could be
interesting to see if it's a HEAD thing or if the slow down was
introduced in 8.3.
Somehow I knew you were going to ask that.
Thanks for putting out pgtune - it's a sorely needed tool.
I had a chance to look over the source code and have a few comments,
mostly about python specific coding conventions.
- The windows specific try block ( line 16 ) raises a ValueError vs
ImportError on my debian machine. Maybe it would be
FYI, this is not limited to PostGIS GIST, it appears to be all GIST
(gid is an integer column and I have loaded btree_gist):
pramsey=# create table ttt as select * from counties;
SELECT
pramsey=# create index gid_bix on ttt using gist (gid);
CREATE INDEX
pramsey=# select count(*) from ttt;
count
I've been assigned to review this patch, but I confess I'm a little
murky on what problem it's trying to solve. Can you explain what I
need to do to recreate the problem?
There's also this comment on the Wiki (not sure why it wasn't posted
to the mailing list...): Dave Page says: This
Who anyone be opposed to ssldir = path as a connection option?
Currently, there is no way to change the homedir method ~/.postgresql
... or am I missing something? I am willing to supply a patch.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers
On Fri, Dec 5, 2008 at 13:58, Andrew Chernow [EMAIL PROTECTED] wrote:
Who anyone be opposed to ssldir = path as a connection option? Currently,
there is no way to change the homedir method ~/.postgresql ... or am I
missing something? I am willing to supply a patch.
You mean something like the
Alex Hunsaker wrote:
On Fri, Dec 5, 2008 at 13:58, Andrew Chernow [EMAIL PROTECTED] wrote:
Who anyone be opposed to ssldir = path as a connection option? Currently,
there is no way to change the homedir method ~/.postgresql ... or am I
missing something? I am willing to supply a patch.
You
On Fri, Dec 5, 2008 at 14:22, Andrew Chernow [EMAIL PROTECTED] wrote:
Alex Hunsaker wrote:
On Fri, Dec 5, 2008 at 13:58, Andrew Chernow [EMAIL PROTECTED] wrote:
Who anyone be opposed to ssldir = path as a connection option?
Currently,
there is no way to change the homedir method
Hitoshi Harada wrote:
I tested the spool performance with David's earlier bigtable:
CREATE TABLE bigtable (
id SERIAL NOT NULL PRIMARY KEY,
timestamp TIMESTAMP NOT NULL
);
-- about 383MB of data
INSERT INTO bigtable (timestamp)
SELECT NOW() + (CAST(RANDOM() * 10 AS INT) || '
Hitoshi Harada Wrote:
2008/12/3 Hitoshi Harada [EMAIL PROTECTED]:
I am randomly trying some issues instead of agg common code (which I
now doubt if it's worth sharing the code), so tell me if you're
restarting your hack again. I'll send the whole patch.
Attached is the updated patch,
On Fri, 5 Dec 2008, Nathan Boley wrote:
- all classes ( 58, 135, 205 ) are 'old-style' classes. I dont see
any reason to use classic classes ( unless Python 2.1 is a support
goal? )
I'm not targeting anything older then 2.4, as that's the oldest version I
have installed anywhere. 2.4 is
On Fri, 2008-12-05 at 17:27 -0500, Greg Smith wrote:
On Fri, 5 Dec 2008, Nathan Boley wrote:
- all classes ( 58, 135, 205 ) are 'old-style' classes. I dont see
any reason to use classic classes ( unless Python 2.1 is a support
goal? )
I'm not targeting anything older then 2.4, as
On Friday 05 December 2008 10:45, Kurt Harriman wrote:
Tom Lane wrote:
Kurt Harriman [EMAIL PROTECTED] writes:
[ make the backend C++-compilable ]
I tested applying this patch to CVS HEAD today and compiling
with --enable-cplusplus with gcc 4.2:
$ ldd postmaster
...
While waiting for a large restore to complete (and investigating why
parts of it were so slow), I came across this scenario. This isn't
quite the same as some previous discussion of hint bits, but I thought
it was something that could probably be taken into account in future.
This also may be
On Fri, Dec 5, 2008 at 2:16 PM, Guillaume Smet [EMAIL PROTECTED] wrote:
On Fri, Dec 5, 2008 at 8:11 PM, Robert Haas [EMAIL PROTECTED] wrote:
Correct. As compared with 8.2.9, ANALYZE was substantially faster,
but query planning was significantly slower.
Thanks also to Greg for reposting my
Looking at eqjoinsel I think it could be improved algorithmically if we keep
the mcv list in sorted order, even if it's just binary sorted order. But I'm
not sure what else uses those values and whether the current ordering is
significant. I'm also not sure it's the only O(n^2) algorithm there
On Friday 05 December 2008 00:05:34 Robert Haas wrote:
On Thu, Nov 27, 2008 at 6:46 PM, Gregory Stark [EMAIL PROTECTED]
wrote:
ANALYZE with default_statistics_target set to 10 takes 13 s. With
100, 92 s. With 1000, 289 s.
That is interesting. It would also be interesting to total up
On Friday 05 December 2008 09:51:50 Kurt Harriman wrote:
Peter Eisentraut wrote:
FYI, we have received patches morally equivalent to yours many times
over the years, and they have all been rejected. You might want to
review the archives about that.
Hi Peter,
I went back as far as 2005
That is interesting. It would also be interesting to total up the time it
takes to run EXPLAIN (without ANALYZE) for a large number of queries.
I wonder if we'd see anything dramatically different using PREPARE...
Well... the point here is to measure planning time. I would think
that
On Fri, 5 Dec 2008, Robert Treat wrote:
Might I suggest you collect all of these various arguments (both for and
against) and patches into a wiki page on the developers wiki?
I'm getting the feeling this is going to take a while to sort out too.
Page with most of the relevant stuff Kurt has
71 matches
Mail list logo
