Mark Kirkwood wrote:
Looks to me like -O2 makes the difference very small (on this
platform/gcc combo) - is 5/169 worth doing?
Ahem - misunderstood your comment here, sorry.
Qingqing Zhou wrote:
compiled with "gcc testbuf.c". I tried -O2 actually, and it turns out
that
the timing is redu
On Wed, Aug 10, 2005 at 10:04:22AM +0200, Martijn van Oosterhout wrote:
> After going through pgsql-general a bit I figured there were a few
> important questions missing from the FAQ, so I wrote some.
Given the additions to the FAQ and suggestions made by Bruce about how
often the questions come
Gavin Sherry wrote:
Or more than one hardware architecture (which you didn't even say what
you tested...)
Well, he tested on SunOS (!) and Linux -- I presume that's two
architectures.
Sun still calls Solaris SunOs - try doing uname -s on a Solaris box (or
look at a buildfarm sola
On Thu, 11 Aug 2005, Andrew Dunstan wrote:
>
>
> Gavin Sherry wrote:
>
> >>Or more than one hardware architecture (which you didn't even say what
> >>you tested...)
> >>
> >>
> >
> >Well, he tested on SunOS (!) and Linux -- I presume that's two
> >architectures.
> >
> >
>
> Sun still calls Solaris
Gavin Sherry wrote:
Sun still calls Solaris SunOs - try doing uname -s on a Solaris box (or
look at a buildfarm solaris build info)
True. But my previous experience in university environments is that SunOS
usually refers to SunOS 2.6
I think I must be a lot older then you.
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> The source code is attached.
>gettimeofday(&start_t, NULL);
>if (method == 0)
>{
> for (i = 0; i < NBuffers; i++)
> k = array[i];
>}
>if (method == 1)
>{
> for (i = 0; i < NBuffers; i++)
> k = start + i*BLCKSZ;
On Tue, 2005-08-09 at 15:01 +, Matt Miller wrote:
> Attached is a patch that implements the "#option select_into_1_row"
> directive as suggested.
Is this patch good-to-go? Can it be queued?
---(end of broadcast)---
TIP 4: Have you searched our
Matt Miller wrote:
> On Tue, 2005-08-09 at 15:01 +, Matt Miller wrote:
> > Attached is a patch that implements the "#option select_into_1_row"
> > directive as suggested.
>
> Is this patch good-to-go? Can it be queued?
We are in feature freeze, so unless there is overwhelming community
suppo
Andreas Pflug wrote:
> Bruce Momjian wrote:
> > Dave Page wrote:
> >
> >
> > The only part I didn't like about the patch is the stat display:
> >
> > test=> select pg_file_stat('postgresql.conf');
> > pg_file_stat
> >
> > -
Bruce Momjian wrote:
Dave Page wrote:
The only part I didn't like about the patch is the stat display:
test=> select pg_file_stat('postgresql.conf');
pg_file_stat
--
Hello,
With gcc-4 on Ubuntu AMD Athlon 2600 Barton:
[EMAIL PROTECTED]:~$ ./a.out
duration round 1 of array method: 0.539 ms
duration round 2 of array method: 0.529 ms
duration round 3 of array method: 0.530 ms
duration round 1 of mul method: 0.258 ms
duration round 2 of mul method: 5.563 ms
dur
On Thu, Aug 11, 2005 at 11:34:43AM -0400, Bruce Momjian wrote:
> Andreas Pflug wrote:
> > Bruce Momjian wrote:
> > > Dave Page wrote:
> > >
> > >
> > > The only part I didn't like about the patch is the stat display:
> > >
> > > test=> select pg_file_stat('postgresql.conf');
> > >
On Thu, Aug 11, 2005 at 01:19:29PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > So, did you try
> >
> > select * from pg_file_stats('postgresql.conf');
>
> Yes, I got:
>
> ERROR: a column definition list is required for functions returning
> "record"
Interesting. I wonder why t
Alvaro Herrera wrote:
> On Thu, Aug 11, 2005 at 01:19:29PM -0400, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > So, did you try
> > >
> > > select * from pg_file_stats('postgresql.conf');
> >
> > Yes, I got:
> >
> > ERROR: a column definition list is required for functions returning
Alvaro Herrera wrote:
> On Thu, Aug 11, 2005 at 11:34:43AM -0400, Bruce Momjian wrote:
> > Andreas Pflug wrote:
> > > Bruce Momjian wrote:
> > > > Dave Page wrote:
> > > >
> > > >
> > > > The only part I didn't like about the patch is the stat display:
> > > >
> > > > test=> sele
On Thu, Aug 11, 2005 at 02:26:16PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Interesting. I wonder why the function is not defined instead with OUT
> > parameters. That way you don't have to declare the record at execution
> > time. See my patch to pgstattuple for an example.
>
>
pgman wrote:
> Andreas Pflug wrote:
> > Bruce Momjian wrote:
> > > Dave Page wrote:
> > >
> > >
> > > The only part I didn't like about the patch is the stat display:
> > >
> > > test=> select pg_file_stat('postgresql.conf');
> > > pg_file_stat
> > >
> >
Ok, I finally got a couple of tests done against CVS from Aug 3, 2005.
I'm not sure if I'm showing anything insightful though. I've learned
that fdatasync and O_DSYNC are simply fsync and O_SYNC respectively on
Linux, which you guys may have already known. There appears to be a
fair performance d
Mark Wong wrote:
> Ok, I finally got a couple of tests done against CVS from Aug 3, 2005.
> I'm not sure if I'm showing anything insightful though. I've learned
> that fdatasync and O_DSYNC are simply fsync and O_SYNC respectively on
> Linux, which you guys may have already known. There appears t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Updated this patch again:
> - vacuum_cost_delay and vacuum_cost_limit can be set per table, as well
> as globally with autovacuum_vacuum_cost_{limit,delay}
>
> - pgstat is reset if recovery is required
>
> - pgstat reset at postmaster start is disable
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Interesting. I wonder why the function is not defined instead with OUT
> parameters.
Because bootstrap mode isn't capable of dealing with array columns,
so you can't define stuff in pg_proc.h that sets up an array of OUT
parameter types. I tried to ap
On Thu, Aug 11, 2005 at 05:13:15PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Updated this patch again:
>
> Applied with minor tweaks --- mostly, fixing it so the custom cost
> settings are applied for ANALYZE as well as VACUUM.
Ok, cool, thanks. I think this complet
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Interesting. I wonder why the function is not defined instead with OUT
> > parameters.
>
> Because bootstrap mode isn't capable of dealing with array columns,
> so you can't define stuff in pg_proc.h that sets up an array of OUT
> p
AgentM <[EMAIL PROTECTED]> writes:
> Attached is a patch which corrects the behavior. I verified that the
> patch does not interfere with normal operation (using psql) but
> unfortunately the code path is virtually impossible to test without a
> really slow connection to a postgresql server [
What if we let the trailing "." or ".." as it is?
On Windows, GetFullPathName() can canonicalize a given path.
$ uname -a
MINGW32_NT-5.0 DEV 1.0.10(0.46/3/2) 2003-10-11 10:14 i686 unknown
$ cat path.c
#include
int
main(void)
{
CHAR Buf[1024];
GetFullPathName("C:\\Temp", 1024
Yep, it is a bug on 8.0.X. Are you suggesting a backpatch? We can do
it. Any objections?
---
William ZHANG wrote:
>
> What if we let the trailing "." or ".." as it is?
>
> On Windows, GetFullPathName() can canonicalize
Bruce Momjian writes:
> Yep, it is a bug on 8.0.X. Are you suggesting a backpatch? We can do
> it. Any objections?
I think he's suggesting that we depend on GetFullPathName(), which seems
a bit pointless considering we have to write the code anyway for other
platforms.
I didn't much like the
Tom Lane wrote:
> Bruce Momjian writes:
> > Yep, it is a bug on 8.0.X. Are you suggesting a backpatch? We can do
> > it. Any objections?
>
> I think he's suggesting that we depend on GetFullPathName(), which seems
> a bit pointless considering we have to write the code anyway for other
> platf
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Bruce Momjian"
Cc: "William ZHANG" <[EMAIL PROTECTED]>;
Sent: Friday, August 12, 2005 10:31 AM
Subject: Re: [PATCHES] Bug in canonicalize_path()
> Bruce Momjian writes:
> > Yep, it is a bug on 8.0.X. Are you suggesting
I wrote:
> I didn't much like the patch as-is; we should think a little harder
> about fixing the logic properly.
Like, say, this. (Very poorly tested but I think it's right.)
regards, tom lane
*** src/port/path.c.origThu Aug 11 21:39:22 2005
--- src/port/path.c
Bruce Momjian writes:
> And then you have this case:
> /usr/local/../bin/../..
AFAICS, the patch I just proposed handles this.
If I recall the code properly, we do not have to make canonicalize_path
remove embedded "." or ".." --- that is, we do not have to simplify
/usr/local/..
Tom Lane wrote:
> Bruce Momjian writes:
> > And then you have this case:
>
> > /usr/local/../bin/../..
>
> AFAICS, the patch I just proposed handles this.
>
> If I recall the code properly, we do not have to make canonicalize_path
> remove embedded "." or ".." --- that is, we do not have to
Bruce Momjian writes:
> But what about "usr/local/../../.."?
What about it? The case of /usr/local/../../.. is handled correctly,
and the case where it's an underspecified relative path doesn't seem
that interesting to me --- certainly that is not so important that we
should get the wrong answer
Tom Lane wrote:
> Bruce Momjian writes:
> > But what about "usr/local/../../.."?
>
> What about it? The case of /usr/local/../../.. is handled correctly,
> and the case where it's an underspecified relative path doesn't seem
> that interesting to me --- certainly that is not so important that we
I have test the following on Windows and Linux:
Windows:
C:\>cd Winnt
C:\WINNT>cd C:\Temp\..\..\
C:\>
Linux:
$ cd /usr/../../
$ pwd
/
We should handle this correctly.
1 Single dot in the path can be removed safety. (except the first one. e.g.
./usr/local)
2 Every dou
"Tom Lane" <[EMAIL PROTECTED]> writes:
>
> This is definitely going to tell us a lot more about the compiler's loop
> strength reduction algorithms than it is going to tell about the time to
> evaluate any one of these expressions in isolation. What's worse, the
> compiler would be quite within i
Here is an updated patch I have just applied (catalog version updated).
I have added these functions:
pg_stat_file()
pg_read_file()
pg_ls_dir()
pg_reload_conf()
pg_rotate_logfile()
I did not include pg_logdir_ls because that was basically pg_ls_dir with
log
Bruce Momjian writes:
> I figured it would be best to leave it alone if we can't process it, but
> if you think it is more imporant to trim in cases like ../.., go ahead.
My recollection of this patch:
2004-08-09 16:20 tgl
* src/: port/exec.c, port/path.c, bin/initdb/initdb.c:
Tom Lane wrote:
> Bruce Momjian writes:
> > I figured it would be best to leave it alone if we can't process it, but
> > if you think it is more imporant to trim in cases like ../.., go ahead.
>
> My recollection of this patch:
>
> 2004-08-09 16:20 tgl
>
> * src/: port/exec.c, port/path.
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> I've patched the code according to your suggestion. Result is:
> [ snip ]
OK, that test seems a little more believable. One point you didn't
consider is that on 64-bit machines, the integer bufnum really has
to be coerced to size_t to avoid overflow i
Bruce Momjian writes:
> Tom Lane wrote:
>> ... it's part of the API contract of canonicalize_path() that it
>> will not return something with trailing "." or "..".
> OK, new patch which I think handles all cases.
> + if (pending_strips > 0)
> + {
> + for (; pending_strips > 0
41 matches
Mail list logo
