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 p
>> > 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 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 fa
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
> 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 th
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 rep
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 relev
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
...
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
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 sti
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 upda
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) || '
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 home
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.
Yo
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 li
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 m
> 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
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
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
>> 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 th
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
> 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 num
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'
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 (pgsql-hackers@postgr
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
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,
>>> 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.
"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 dele
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)
a
>>> 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
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 biza
"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
>
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.
>
> Com
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 te
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 somet
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 an
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
Pet
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
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 this
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
>
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 (pgsql-hackers@postgr
>
> 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 se
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
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 Star
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
after
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 mino
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 (pgsql-hacke
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
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'
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 mora
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
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
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
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_co
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
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]
http://sepgsql.googlecode.com/files/sepostgresql-policy-
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 cal
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 archive
(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, all
(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 t
(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 and
(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 extensi
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
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 inten
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 pag
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 yo
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
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
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 mu
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 memor
71 matches
Mail list logo
