Pavel Stehule wrote:
> I am playing with methods. It's +/- function with first hidden arguments.
>
> example: sin(10) ~ (10).sin() is equivalent.
> legal is substring('',1,3).upper() too etc
>
> I spent some time with bison (without success).
I don't think you can actually resolve this in the
On Nov 22, 2007 6:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Are you examining only "trivial" queries? I've been able to identify a
> couple of new planner hotspots that could explain some slowdown if the
> planning time is material compared to the execution time. If you're
> seeing a slowdown
Simon Riggs wrote:
> On Wed, 2007-11-21 at 09:47 +, Peter Childs wrote:
>> How about this, emit a warning on shutdown and fail to shutdown until
>> the backup has finished.
>
> That would be reasonable for -m smart shutdown.
>
> We would then be treating the backup as a connection.
>
> ...bu
On Nov 22, 2007 2:17 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Another issue is that on read-only transactions there's an extra
> gettimeofday() call caused by pgstat_report_tabstats, which could be a
> problem on machines with slow gettimeofday(). However that shouldn't
> happen if you've got tra
Hi All,
I was exploring through the BuildFarm specific perl
script run_build.pl.
I executed the perl script and it went on file by
downloading the latest PostgreSQL source code that is
8.3Beta2, after successful completion of the script it
creates the required set of logfiles in the
"lastrun-log
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> I'm not saying my benchmark is perfectly relevant: I made it
> excessively simple on purpose. I just see a general slow down which is
> quite consistent accross all the tests I did (with pgbench or the
> application) and I'd really like to know if it's
On Nov 21, 2007 7:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> FWIW, the test cases I was just comparing are entirely CPU-bound ---
> vmstat says there are no disk reads happening at all. Now I only got a
> 3% drop, so that may not be the same effect Guillaume is seeing. But
> the whole thing is
I wrote:
> The weird thing is that after a couple of hours of poking at it with
> oprofile and other sharp objects, I have no idea *why* it's slower.
> oprofile shows just about the same relative percentages for all the
> hot-spot functions in the backend.
However, some comparisons with gprof show
On Nov 22, 2007 12:49 AM, Greg Smith <[EMAIL PROTECTED]> wrote:
> Hard drives deliver a higher transfer rate at their inner
> portions, typically the start of the disk from the operating system's
> perspective.
It could have been a good point if it was seq scans of large tables.
It's only index sc
On Nov 22, 2007 12:59 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> It's not that autovacuum is now
> on by default --- turning it off made no particular difference.
Tested that also a few hours ago. No difference.
> It's not that stats collection is now on by default --- ditto.
Same here. My 8.2 ha
Greg Smith <[EMAIL PROTECTED]> writes:
> On Wed, 21 Nov 2007, Guillaume Smet wrote:
>> *** 8.2 ***
>> tps = 853.360277 (including connections establishing)
>>
>> *** 8.3 ***
>> tps = 784.819087 (including connections establishing)
> This is an 8% drop. I've seen a larger difference than that bet
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> I took a couple of very simple read only queries executed in the pages
> to create a pgbench script and I have the following results:
Hmm ... I can reproduce a consistent difference of about three percent
between 8.2 and HEAD. Using pgbench's built-i
On Wed, 21 Nov 2007, Guillaume Smet wrote:
*** 8.2 ***
tps = 853.360277 (including connections establishing)
*** 8.3 ***
tps = 784.819087 (including connections establishing)
This is an 8% drop. I've seen a larger difference than that between two
identical installations of the same version
On Nov 22, 2007 12:07 AM, Gregory Williamson
<[EMAIL PROTECTED]> wrote:
> I've been running some fairly heavy read-only tests (5 minutes duration)
> against 8.3beta2 and 8.2.5 and 8.1.10 and are getting slightly faster
> numbers for 8.2.5 over 8.1 and 8.3beta2 looks consistently faster by a few
>
On Nov 21, 2007 10:09 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> Please do tests of at least 2 minutes duration. A 1.25 second test isn't
> enough.
I already run far longer tests. It's not a matter of running a test
for long, it's just that each unique query is a little bit slower.
Moreover it'
On Wed, 21 Nov 2007, Tom Lane wrote:
Whether 16MB is still a reasonable default segment size is worth
questioning, though I don't think that increasing it is an open-and-shut
proposition.
I don't think it's a reasonable change to make right now. I think 16MB is
already too big for some peopl
FWIW,
>
> Please do tests of at least 2 minutes duration. A 1.25 second test isn't
> enough. Please confirm you have VACUUM ANALYZED each db beforehand.
>
> Have you checked that the EXPLAIN ANALYZEs are essentially identical
> also? Is the data identical on both systems?
>
I've been running s
On 21 Nov, 2007, at 11:38 , Tom Lane wrote:
Brandon Maust <[EMAIL PROTECTED]> writes:
yes, it is sucking it in (via handy.h), at least in 10.5:
#if 1 /* always on Mac OS X */
# include
# ifndef HAS_BOOL
#define HAS_BOOL 1
# endif
#endif
Nasty. I'm still surprised that there's no r
On Wed, 2007-11-21 at 20:04 +0100, Guillaume Smet wrote:
> number of clients: 1
> number of transactions per client: 1000
> number of transactions actually processed: 1000/1000
> tps = 784.819087 (including connections establishing)
> tps = 786.884214 (excluding connections establishing)
>
> All
hello
I am playing with methods. It's +/- function with first hidden arguments.
example: sin(10) ~ (10).sin() is equivalent.
legal is substring('',1,3).upper() too etc
I spent some time with bison (without success).
indirection_el:
'.' attr_name
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Mon, 2007-11-19 at 02:50 -0700, Kris Jurka wrote:
>> Can we backport this fix? I'm trying to setup a new windows build
>> environment and this is currently halting my progress for back branches.
> Technically, it's fairly easy. And given that it's
Brandon Maust <[EMAIL PROTECTED]> writes:
> yes, it is sucking it in (via handy.h), at least in 10.5:
> #if 1 /* always on Mac OS X */
> # include
> # ifndef HAS_BOOL
> #define HAS_BOOL 1
> # endif
> #endif
Nasty. I'm still surprised that there's no redefinition warning for
"false" and "
I wrote:
> Apparently 5.8.8
> is sucking stdbool.h into the compile where 5.8.6 did not. Can you
> track down just what the inclusion path is?
I pulled down the perl 5.8.8 sources and cannot find a reference to
stdbool.h anywhere. What I do find is that "handy.h" defines what
Perl thinks bool is
On 21 Nov, 2007, at 10:50 , Tom Lane wrote:
Brandon Maust <[EMAIL PROTECTED]> writes:
On 21 Nov, 2007, at 08:39 , Tom Lane wrote:
Seems the question is not so much about OS X as it is about what
perl you're using ...
it's 5.8.8, as provided by apple (same for gcc, etc):
perl on OS X does
Hi -hackers,
I'm currently testing 8.3devel on the database of one of our customers
(4 GB database used by a website - mostly read only activity). My main
concern was to discover if there is any query choosing a bad plan in
8.3 for one reason or another.
While I didn't find anything far slower tha
>>> On Wed, Nov 21, 2007 at 12:32 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Has this issue been a real problem? If so, probably we should consider
>> adjusting ANALYZE for 8.3 per your proposal.
>
> I'm not sure. Upth
Brandon Maust <[EMAIL PROTECTED]> writes:
> On 21 Nov, 2007, at 08:39 , Tom Lane wrote:
>> Seems the question is not so much about OS X as it is about what
>> perl you're using ...
> it's 5.8.8, as provided by apple (same for gcc, etc):
> perl on OS X does look to be constitutively defining a 'bo
On 21 Nov, 2007, at 08:39 , Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Nothing fatal? Huh, you have a curious idea about warnings. This
makes
me think you have the wrong headers or something -- the argument
mentioned in all these cases is bool, so maybe there is an ABI
inco
On Mon, 2007-11-19 at 02:50 -0700, Kris Jurka wrote:
> Magnus Hagander wrote:
> > Log Message:
> > ---
> > New versions of mingw have gettimeofday(), so add an autoconf test
> > for this.
> >
>
> Can we backport this fix? I'm trying to setup a new windows build
> environment and this i
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Should we attempt to adjust VACUUM's accounting as well, or leave it
>> for 8.4? For that matter, should adjusting ANALYZE be left for 8.4?
>> Thoughts?
> Has this issue been a real problem? If so, probably we should consider
> adju
>>> On Wed, Nov 21, 2007 at 11:24 AM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> In poking around the logs just now, I noticed one message I'd like
>> to squelch. Run against Milwaukee County's recent log files:
>
>> gre
On Wed, 2007-11-21 at 12:24 -0500, Tom Lane wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> wrote:
> >> Just to clarify: I don't object to lowering "successfully archived"
> >> messages to DEBUG1, if the field consensus is that it's too chatty.
> >> What I di
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2007-11-21 at 18:16 +0100, Zeugswetter Andreas ADI SD wrote:
>> Maybe it is time for making WAL segment size
>> changeable in the conf with a clean shutdown.
> I think its too late in the release cycle to fully consider all the
> implications of th
Hannes Eder worte:
We wrote a little contrib module, which we'd like to share. It can be
used to generate random datasets as they have been used in
[Borzsonyi2001] and related work.
[snip]
We release a command line version of this module. See:
http://randdataset.projects.postgresql.org/
the so
On Wed, 2007-11-21 at 18:16 +0100, Zeugswetter Andreas ADI SD wrote:
> > Perhaps we should move the successful archived message to DEBUG1 now,
> > except for the first message after the archiver starts or when the
> > archive_command changes, plus one message every 255 segments?
> > That would red
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Just to clarify: I don't object to lowering "successfully archived"
>> messages to DEBUG1, if the field consensus is that it's too chatty.
>> What I didn't like was the idea of logging some events but not other
>
> Perhaps we should move the successful archived message to DEBUG1 now,
> except for the first message after the archiver starts or when the
> archive_command changes, plus one message every 255 segments?
> That would reduce the log volume in the normal case without
endangering
> our ability to
>>> On Wed, Nov 21, 2007 at 10:57 AM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> On Wed, 2007-11-21 at 11:27 -0500, Tom Lane wrote:
>>> That would confuse people terribly, and it *would* endanger our ability
>>> to see what was
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2007-11-21 at 11:27 -0500, Tom Lane wrote:
>> That would confuse people terribly, and it *would* endanger our ability
>> to see what was happening, 254 times out of 255.
> That's my feeling too, just wanted to check it still made sense for
> y'all.
On Wed, 2007-11-21 at 11:27 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Perhaps we should move the successful archived message to DEBUG1 now,
> > except for the first message after the archiver starts or when the
> > archive_command changes, plus one message every 255 segme
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Nothing fatal? Huh, you have a curious idea about warnings. This makes
> me think you have the wrong headers or something -- the argument
> mentioned in all these cases is bool, so maybe there is an ABI
> incompatibility somewhere.
Yeah, and it's hard
Simon Riggs <[EMAIL PROTECTED]> writes:
> Perhaps we should move the successful archived message to DEBUG1 now,
> except for the first message after the archiver starts or when the
> archive_command changes, plus one message every 255 segments? That would
> reduce the log volume in the normal case
>>> On Wed, Nov 21, 2007 at 8:49 AM, in message
<[EMAIL PROTECTED]>, Simon Riggs <[EMAIL PROTECTED]>
wrote:
> Perhaps we should move the successful archived message to DEBUG1 now,
> except for the first message after the archiver starts or when the
> archive_command changes, plus one message ev
Euler Taveira de Oliveira wrote:
> Hi,
>
> Looking again at bug report [1], I agree that's a glibc bug. Numbers in
> pt_BR has its format 1.234.567,89; sometimes the format 1234567,89 is
> acceptable too, ie, the thousand separator is optional. I guess that
> some locales use the 'optional' thousa
Simon Riggs wrote:
> That will make PITRs fail:
>
> 1. pg_start_backup()
> 2. backup
> 3. shutdown, removes backup_label
> 4. pg_stop_backup()
>
> step 4 will now fail because of a missing backup_label file.
Wait a minute:
pg_stop_backup() will also fail in the current setup,
because after reco
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The spec doesn't allow casts between xml and text (varchar) at all. The way
> I appear to have derived the current behavior from the spec is that this is
> interpreted as an implicit XMLSERIALIZE call in the context of a prepared
> statement, which
On Wed, 2007-11-21 at 14:45 +0100, Rudolf van der Leeden wrote:
> In v8.2.4 we are currently switching archiving on/off on the fly by
> just inserting an archiving command.
> Now we have got a separate option for handling the on/off state.
> That's ok.
> But the note "change requires restart"
On Wed, 2007-11-21 at 15:04 +0100, Albe Laurenz wrote:
> Simon Riggs wrote:
> >> If somebody stops the postmaster while an online backup is
> >> in progress, there is no warning or nothing. Only the server
> >> will fail to restart.
> >
> > Well, it seems best not to do this. There is always a nee
Simon Riggs wrote:
>> If somebody stops the postmaster while an online backup is
>> in progress, there is no warning or nothing. Only the server
>> will fail to restart.
>
> Well, it seems best not to do this. There is always a need
> for a careful
> procedure to manually shutdown a live server, i
Hi,
I just installed v8.3beta3 and discovered that the way WAL archiving
is handled has changed.
From postgresql.conf:
#archive_mode = off # allows archiving to be done
(change requires restart)
#archive_command = '' # command to use to archive a logfile
segment
On Wed, 2007-11-21 at 09:47 +, Peter Childs wrote:
> How about this, emit a warning on shutdown and fail to shutdown until
> the backup has finished.
That would be reasonable for -m smart shutdown.
We would then be treating the backup as a connection.
...but not for a fast shutdown.
Any
Tom Lane wrote:
> I feel fairly comfortable with this analysis for ANALYZE, and the
> patch I posted yesterday can easily be adjusted to accommodate it.
> However, what of VACUUM? As that code stands, every non-removable
> tuple (including RECENTLY_DEAD ones) is counted as live, and the
> dead-tu
Am Mittwoch, 21. November 2007 schrieb Tom Lane:
> "Matt Magoffin" <[EMAIL PROTECTED]> writes:
> > Ugh, you're right of course! Somehow I had this wrong. So I tried to
> > create an index on the xml[] result by casting to text[] but I got the
> > "function must be immutable" error. Is there any rea
B. Maust wrote:
> there were a few warnings building plperl:
>
> gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -I.
> -I../../../src/include
> -I/System/Library/Perl/5.8.8/darwin-thread-multi-2lev
On 21/11/2007, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2007-11-21 at 09:04 +0100, Albe Laurenz wrote:
>
> > If somebody stops the postmaster while an online backup is
> > in progress, there is no warning or nothing. Only the server
> > will fail to restart.
>
> Well, it seems best not to
On Wed, 2007-11-21 at 09:04 +0100, Albe Laurenz wrote:
> If somebody stops the postmaster while an online backup is
> in progress, there is no warning or nothing. Only the server
> will fail to restart.
Well, it seems best not to do this. There is always a need for a careful
procedure to manually
I mentioned in #postgres a bit ago to no avail that I couldn't get my
plperl stored procedures to work after upgrading to OS X 10.5, with only a
obtuse "ERROR: null prosrc". I was using 8.2.4 and didn't want to make a
big deal about a non-current release, but today I had a chance to build
8.3
>> If the postmaster is stopped with 'pg_ctl stop' while an
>> online backup is in progress, the 'backup_label' file will remain
>> in the data directory.
[...]
>> the startup process will fail with a message like this:
[...]
>> PANIC: could not locate required checkpoint record
>> HINT: If you a
58 matches
Mail list logo
