Subject: [HACKERS] Inputting money
I notice that I have to put single quotes around money amounts if there
is a decimal point in the value. I appears to be happening because there
is something changing things like "123.45" to "123.450000" and the code
has a problem with that. There may be a better way to fix this but here
is a simple change to cash.c that lets it accept trailing zeroes.
Add comparison operators to boolean and smaller/larger operators to datetime
and timespan. Fix int4 overflow math problem in timespan comparison operators.
Here are patches which should help fix timezone problems in the
datetime and abstime code. Also, I repatched varlena.c to add in
some comments and a little error checking on top of Vadim's earlier
repairs. There are slight mods to the circle data type to have the
distance operator between circles measure the distance between
closest points rather than between centers.
Subject: [PATCHES] Patches for compiling 6.1 on Digital Unix 3.2c
Attached to this message are the patches I needed to compile 6.1 cleanly
under Digital Unix 3.2c with DEC cc.
I hope these are the last ones. At least, the number of files needing a
patch has decreased noticeably since I sent my previous patches. Nice work
:-)
One of the patches is a bug fix, but I'm including it here anyway.
With these patches applied, the beast seems to work properly. However,
I've done only some preliminary tests. More on this later (but hopefully
before the April 30 deadline... :-)
postgres backend processes end up as so called zombies. It seems that
only Linux a.out (libc.4.6.27) systems are affected.
By:
Wolfgang Roth <roth@statistik.uni-mannheim.de>
nestloop's join clauses doesn't work in some cases:
* 1. fix_indxqual_references may change varattno-s in
* inner_indxqual;
* 2. clauses may be commuted
Subject: Re: [PATCHES] SET DateStyle patches
On Tue, 22 Apr 1997, Thomas Lockhart wrote:
> Some more patches! These (try to) finish implementing SET variable TO value
> for "DateStyle" (changed the name from simply "date" to be more descriptive).
> This is based on code from Martin and Bruce (?), which was easy to modify.
> The syntax is
>
> SET DateStyle TO 'iso'
> SET DateStyle TO 'postgres'
> SET DateStyle TO 'sql'
> SET DateStyle TO 'european'
> SET DateStyle TO 'noneuropean'
> SET DateStyle TO 'us' (same as "noneuropean")
> SET DateStyle TO 'default' (current same as "postgres,us")
>
> ("european" is just compared for the first 4 characters, and "noneuropean"
> is compared for the first 7 to allow less typing).
>
> Multiple arguments are allowed, so SET datestyle TO 'sql,euro' is valid.
>
> My mods also try to implement "SHOW variable" and "RESET variable", but
> that part just core dumps at the moment. I would guess that my errors
> are obvious to someone who knows what they are doing with the parser stuff,
> so if someone (Bruce and/or Martin??) could have it do the right thing
> we will have a more complete set of what we need.
>
> Also, I would like to have a floating point precision global variable to
> implement "SET precision TO 10" and perhaps "SET precision TO 10,2" for
> float8 and float4, but I don't know how to do that for integer types rather
> than strings. If someone is fixing the SHOW and RESET code, perhaps they can
> add some hooks for me to do the floats while they are at it.
>
> I've left some remnants of variable structures in the source code which
> I did not use in the interests of getting something working for v6.1.
> We'll have time to clean things up for the next release...
Subject: [PATCHES] date/time timezone patches (mail bounced?)
Here are some hacks to get timezone behavior for the various time
data types to be compatible with v6.0. Although we have some hooks
already installed to get timezone info from the client to the
server, it still isn't clear if that can correctly transfer enough
timezone info to make the behavior the same as if timezone info
were derived from the server as is now the case. We certainly
won't resolve it in a day, so I think we are stuck with server-only
timezones for v6.1.
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
Subject: [PATCHES] 970417: some large object patches
Two patches here, made against 970417. Both have to do with large
objects:
1. lobjfuncs was not initialized in PQconnectdb. This causes
failure later if large objects are used. (Someone already
caught this error in PQsetdb.)
2. Postgres functions lo_import and lo_export sometimes
produce garbage for the file names because the filename
strings aren't always terminated by \0. (VARDATA isn't
necessarily null terminated.)
Subject: [PATCHES] 970417: two more patches for large objects
Here are two more patches:
1. pg_getint doesn't properly set the status flag when
calling pqGetShort or pqGetLong. This is required when
accessing large objects via libpq. This, combined with
problem 1 above causes postgres to crash when postgres
tries to print out the message that the status was not
good.
2. ExceptionalCondition crashes when called with detail =
NULL. This patch prevents dereferencing the NULL.
Subject: [HACKERS] Patch: set date to euro/us postgres/iso/sql
Here a patch that implements a SET date for use by the datetime
stuff. The syntax is
SET date TO 'val[,val,...]'
where val is us (us dates), euro (european dates), postgres,
iso or sql.
Thomas is working on the integration in his datetime module.
I just needed to get the patch out before it went stale :)
table. The table name is de-allocated by the CommitTransactionCommand()
in vc_init() before it is copied in VacRel.data and sometimes this causes
a SIGSEGV. My patch simply moves the strcpy before vc_init.
Submitted by Massimo Dal Zotto <dz@cs.unitn.it>.
index tuple (logical position within A LEVEL). bti_oid & bti_dummy
taken off from BTItemData.
2. Fix for multi-column indices (nbtsearch.c):
_bt_binsrch() - for searches on internal pages having keysize <
number of attrs we point at the last item < the scankey, not at the
first item = the scankey;
_bt_moveright() - if keysize < number of attrs we compare scankey with
_last_ item on current page to decide should we move right or
not.
Subject: [HACKERS] Money integration patches
Here are patches to integrate the money data type. I have included
some math and aggregate functions and have made the locale support optional
by #ifdef USE_LOCALE bracketing of functions.
Modules affected are:
builtins.h.patch
cash.c.patch
cash.h.patch
main.c.patch
pg_aggregate.h.patch
pg_operator.h.patch
pg_proc.h.patch
pg_type.h.patch
I changed the data type to be pass-by-reference rather than by-value
to pave the way for a larger internal representation (64-bit ints?).
Also, I changed the tabbing of cash.c and cash.h to match most of
the other Postgres source code files (4 space indent, 8 spaces == 1 tab).
The locale stuff should be tested under another convention (Russian?)
but I don't know what the correct results should be so perhaps someone
else can give them a try. Will update docs and regression tests in
the next few days.
invalid macro definitions, the compiler complains about:
"pqcomprim.c", line 48.9: 1506-275 (S) Unexpected text ';' ignored.
"pqcomprim.c", line 61.9: 1506-275 (S) Unexpected text ';' ignored.
The ';' terminating the macro definition ntoh_s(n) on line 27 and
ntoh_l(n) on line 28 should be removed.
Pointed out by: Olaf Mittelstaedt <MSTAEDT@va-sigi.va.fh-ulm.de>
pg_proc.h still needs modifying, but this gets it in there so that we can
get around any compiler bugs. Will try and get the pg_proc.h entries done
up later tonight...
Subject: Re: [HACKERS] GEQO and views (rules)
Oke, this was caused by a classic bug :-/
I thougth, root->base_relation_list_ could be
represented as relid string 1-2-3-4- etc.
Instead, in case of views, the count of relids doesn't start with "1" but
maybe 4-5-6- etc . :-(
GEQO patch follows ... views are now all right.
2. PageWeights are variables now.
3. Fixed using ceil((double)selec*indextuples) as estimation
for expected heap pages: ceil((double)selec*relpages) now.
use sum(npages)/((nkeys == 1) ? 1 : nkeys + 1) as expected index page
estimation for multi-key quals - instead of sum(npages).
In old code npages for x > 10 and x < 20 is twice as for x > 10 - cool ?
Subject: [HACKERS] Fix for European dates
This apparently fixes the European date reading problem reported
by several (European) bleeding edge adopters. I tried a few test
cases and it doesn't break the non-EuroDate cases in my test suite.
FreeBSD
The Makefile(s) have all been cleaned up such that there is a single
LDFLAGS vs LD_ADD or LDADD or LDFLAGS or LDFLAGS_BE. The Makefile(s)
should be alot more straightforward then they were before...and
consistent
Subject: [HACKERS] timestamp.c changes
I sent in changes previously and they were rejected because they didn't
follow ANSI spec. Here is the input part of the changes again. Even
though it allows more flexibility for inputting different formats, it
is also backwards compatible with the standard version. I have also
not changed the output format so it will still output the ANSI forms.
Is this acceptable to everyone?
Subject: [HACKERS] Aggregate function patches
Here are the aggregate function patches I originally sent in last December.
They fix sum() and avg() behavior for ints and floats when NULL values are
involved.
I was waiting to resubmit these until I had a chance to write a v6.0->v6.1
database upgrade script to ensure that existing v6.0 databases which have
not been reloaded for v6.1 do no break with the new aggregate behavior.
These scripts are included below. It's OK with me if someone wants to do
something different with the upgrade strategy, but something like this
was discussed a few weeks ago.
Also, there were a couple of small items which cropped up in doing a clean
install of 970403 (actually 970402 + 970403 changes since the full 970403
tar file appears to be damaged or at least suspect). They are the first
two patches below and can be omitted if desired (although I think they
aren't dangerous :).
Subject: [HACKERS] More date time functions
Here are some additional patches mostly related to the date and time
data types. It includes some type conversion routines to move between
the different date types and some other date manipulation routines such
as date_part(units,datetime).
I noticed Edmund Mergl et al's neat trick for getting function overloading
for builtin functions, so started to use that for the date and time stuff.
Later, if someone figures out how to get function overloading directly
for internal C code, then we can move to that technique.
These patches include documentation updates (don't faint!) for the built-in
man page. Doesn't yet include mention of timestamp, since I don't know
much about it and since it may change a bit to become a _real_ ANSI timestamp
which would include parser support for the declaration syntax (what do you
think, Dan?).
The patches were developed on the 970330 release, but have been rebuilt
off of the 970402 release. The first patch below is to get libpq to compile,
on my Linux box, but is not related to the rest of the patches and you can
choose not to apply that one at this time. Thanks in advance, scrappy!
Subject: [HACKERS] Patch: SET var TO 'val'
Here is a patch that adds a "SET variable TO 'somevalue'" capability
to the parser, and then calls the SetPGVariable() function (which does
just issue a elog(NOTICE) to see whether it works).
That's the framework for adding timezone/date format/language/...
stuff.
Subject: [HACKERS] locale patches !
Hi there,
here are little patches to get Postgres 6.1 works with locale stuff.
This is a patch against 970402.tar.gz, there are no problem to apply them
by hand to 6.0 release. Collate stuff tested about 1-2 months in real
working database but I'm sure there must be no problem. US hackers
could vote against locale implementation ( locale for sure will affect to
speed of postgres ), so I introduce variable USE_LOCALE which
controls locale stuff. Non-US users now could use ~* operator
for searching and <order by> for strings with nation alphabet.
Please, don't forget, as I did first time, to set environment variable
LC_CTYPE and LC_COLLATE because backend get locale information from them.
I start postmaster from a little script, assuming that shell is Bash shell
it looks like:
#!/bin/sh
export LC_CTYPE=koi8-r
export LC_COLLATE=koi8-r
postmaster -B 1024 -S -D/usr/local/pgsql/data/ -o '-Fe'
Subject: [HACKERS] Small date patches (resubmitted)
Here a some small patches for the date/time code. They set the default
output format for the datetime type to the traditional Postgres
style, and fix a date debugging declaration. I submitted these
a couple of days ago, but they might have gotten lost...
NOTE: the second patch to dt.c is what I believe D'Arcy submitted as well,
that I claimed was taken out...sorry D'Arcy, my fault :(
Subject: Re: [HACKERS] abstime "now" broken
Yes, I broke 'now' :( with an attempt at a bug fix involving
servers running in the UTC/GMT timezone. These patches fix
the problem, and have been tested in GMT (+00 hours),
PST (-08), and NZT (+12) timezones which exercized the code for
various cases including across day boundaries. btw, this code
fixes the same type of problem for 'today', 'yesterday', 'tomorrow',
for DATETIME, ABSTIME, DATE and TIME types.
The bugfix itself is quite small, but I have accumulated other
changes in the datetime data type and include them here also.
One set of changes involves printing ISO-formatted dates and
is in response to the helpful information from Kurt Lidl regarding
ANSI SQL dates. I'll send another e-mail sometime soon discussing
more issues he has raised...
Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com>
To: hackers@hub.org
Subject: [HACKERS] tmin writeback optimization
I was doing some profiling of the backend, and noticed that during a certain
benchmark I was running somewhere between 30% and 75% of the backend's CPU
time was being spent in calls to TransactionIdDidCommit() from
HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that
changed rows' transactions had in fact been committed even though the rows'
tmin values had not yet been set.
When a query looks at a given row, it needs to figure out whether the
transaction that changed the row has been committed and hence it should pay
attention to the row, or whether on the other hand the transaction is still
in progress or has been aborted and hence the row should be ignored. If
a tmin value is set, it is known definitively that the row's transaction
has been committed. However, if tmin is not set, the transaction
referred to in xmin must be looked up in pg_log, and this is what the
backend was spending a lot of time doing during my benchmark.
So, implementing a method suggested by Vadim, I created the following
patch that, the first time a query finds a committed row whose tmin value
is not set, sets it, and marks the buffer where the row is stored as
dirty. (It works for tmax, too.) This doesn't result in the boost in
real time performance I was hoping for, however it does decrease backend
CPU usage by up to two-thirds in certain situations, so it could be
rather beneficial in high-concurrency settings.
Subject: [HACKERS] backend/utils/adt/timestamp.c
Back to this timezone stuff. The struct tm has a field (tm_gmtoff) which
is the offset from UTC (GMT is archaic BTW) in seconds. Is this the
value you are looking for when you use timezone? Note that this applies
to NetBSD but it does not appear to be in either ANSI C or POSIX. This
looks like one of those things that is just going to have to be hand
coded for each platform.
Why not just store the values in UTC and use localtime instead of
gmtime when retrieving the value?
Also, you assume the time is returned as a 4 byte integer. In fact,
there is not even any requirement that time be an integral value. You
should use time_t here.
The input function seems unduly restrictive. Somewhere in the sources
there is an input function that allows words for months. Can't we do
the same here?
There is a standard function, difftime, for subtracting two times. It
deals with cases where time_t is not integral. There is, however, a
small performance hit since it returns a double and I don't believe
there is any system currently which uses anything but an integral for
time_t. Still, this is technically the correct and portable thing to do.
The returns from the various comparisons should probably be a bool.
of endian.h. I figure that if it exists it's pretty sure that it has
the byte order information and we may catch some other ports without
any further testing.
From: "D'Arcy J.M. Cain" <darcy@druid.net>
Subject: [HACKERS] More patches for date/time
I have accumulated several patches to add functionality to the datetime
and timespan data types as well as to fix reported porting bugs on non-BSD
machines. These patches are:
dt.c.patch - add datetime_part(), fix bugs
dt.h.patch - add quarter and timezone support, add prototypes
globals.c.patch - add time and timezone variables
miscadmin.h.patch - add time and timezone variables
nabstime.c.patch - add datetime conversion routine
nabstime.h.patch - add prototypes
pg_operator.h.patch - add datetime operators, clean up formatting
pg_proc.h.patch - add datetime functions, reassign conflicting date OIDs
pg_type.h.patch - add datetime and timespan data types
The dt.c and pg_proc.h patches are fairly large; the latter mostly because I tried
to get some columns for existing entries to line up.
nicer. Also, I grabbed my copy of the Informix manual, and
added a couple of variables that make sense (formats for
money, time, a language setting, a timezone).
- New functions SetPGVariable() and GetPGVariable() in tcop/*.
These don't actually do anything for the moment, but should
be enough to implement the SET var_name TO var_val in the
parser?
SetPGVariable() expects just two strings, the var_name and
the var_value from above, and is expected to do the right thing.
Returns TRUE if everything okay.
From: "Martin J. Laubach" <mjl@wwx.vip.at>
Actually required by multi-column indices support.
We still don't use btree for 'A is (not) null', but
now btree keep items with NULL attrs using single rule
for placing/finding items on pages:
NULLs greater NOT_NULLs and NULL = NULL.
+ Bulkload code (nbtsort.c) support for multi-column indices
building and NULLs.
+ Fix for btendscan()->pfree(scanopaque) from Chris Dunlop.
Subject: [HACKERS] backend/utils/adt/nabstime.c
There is a problem with some of the calls to strftime. The second arg is
missing. In all cases the buffer is CTZName which, according to the
file init/globals.c, is char CTZName[8] so I have added this value.
I know there should be a #define set up for this but I wasn't sure
which header to put it in.
Subject: [HACKERS] libpq/pqcomm stuff and Solaris byte order
I decided to go ahead with the required changes since no one else seems
to. I don't guarantee that it is perfect but with these changes the
package actually compiles. While I was at it I added to the Sparc
Solaris header to define the byte order. Note that NetBSD sets this
in the system headers so it wasn't required there.
In particular, someone may want to check whether I removed the correct
84 lines from backend/libpq/pqcomprim.c.
Subject: [HACKERS] auth.c for kerberos.
I made pgsql with eBones(international version of Kerberos4). The
following modification was needed. And I added read permition for
group to srvtab instead of running postmaster as root.
According to man page under FreeBSD for sys_errlist[], strerror() should be
used instead...not sure if this will break other systems, so only changing
two files for now, and we'll see what "errors" it turns up
of common routines in pqcomprim.c (pq communication primitives).
Not all adapted to it yet, but it's a start.
- Rewritten some of those routines, to write/read bigger chunks of
data, precomputing stuff in buffers instead of sending out byte
by byte.
- As a consequence, I need to know the endianness of the machine.
Currently I rely on getting it from machine/endian.h, but this
may not be available everywhere? (Who the hell thought it was
a good idea to pass integers to the backend the other way around
than the normal network byte order? *argl*)
- Libpq looks in the environment for magic variables, and upon
establishing a connection to the backend, sends it queries
of the form "SET var_name TO 'var_value'". This needs a change
in the backend parser (Mr. Parser, are you there? :)
- Currently it looks for two Env-Vars, namely PG_DATEFORMAT
and PG_FLOATFORMAT. What else makes sense? PG_TIMEFORMAT?
PG_TIMEZONE?
From: "Martin J. Laubach" <mjl@wwx.vip.at>
Subject: [HACKERS] Patches for 970316 compilation
I made a small pre-emptive change in the new datetime code to eliminate
calls to infnan(). Hopefully this will make Solaris (and probably other
non-GNUlib) systems happier. Didn't find fe-connect.h in the 970316
distribution, so made one up. Also, one of the test routines needs an
update for the geo-decls.h -> geo_decls.h name change.
Patches appear below...
Subject: [HACKERS] lock debug trace
This is an update to my previous patches for lock debugging, already applied
to the current sources. It adds some improvements in the output messages and
some more output in WaitOnLock(). I have used with success to trace a nasty
deadlock condition on pg_listener.
> Please apply them to the direcory "backend/optimizer/geqo".
> Two new files with different crossover techniques are included.
> Standard procedure is optimization by means of "geqo_erx.c"
> (Edge Recombination Crossover).
From: "Martin S. Utesch" <utesch@aut.tu-freiberg.de>
Subject: [HACKERS] password authentication
This patch adds support for plaintext password authentication. To use
it, you add a line like
host all 0.0.0.0 0.0.0.0 password pg_pwd.conf
to your pg_hba.conf, where 'pg_pwd.conf' is the name of a file containing
the usernames and password hashes in the format of the first two fields
of a Unix /etc/passwd file. (Of course, you can use a specific database
name or IP instead.)
Then, to connect with a password through libpq, you use the PQconnectdb()
function, specifying the "password=" tag in the connect string and also
adding the tag "authtype=password".
I also added a command-line switch '-u' to psql that tells it to prompt
for a username and password and use password authentication.
Subject: [HACKERS] linux/alpha patches
These patches lay the groundwork for a Linux/Alpha port. The port doesn't
actually work unless you tweak the linker to put all the pointers in the
first 32 bits of the address space, but it's at least a start. It
implements the test-and-set instruction in Alpha assembly, and also fixes
a lot of pointer-to-integer conversions, which is probably good anyway.
Subject: [HACKERS] linux/alpha patches
These patches lay the groundwork for a Linux/Alpha port. The port doesn't
actually work unless you tweak the linker to put all the pointers in the
first 32 bits of the address space, but it's at least a start. It
implements the test-and-set instruction in Alpha assembly, and also fixes
a lot of pointer-to-integer conversions, which is probably good anyway.
Subject: [HACKERS] equal column and table name patch
This fixes a bug where selects fail when there is a column with the same
name as the table it's a part of.
Subject: [HACKERS] better access control error messages
This patch replaces the 'no such class or insufficient privilege' with
distinct error messages that tell you whether the table really doesn't
exist or whether access was denied.
Subject: [HACKERS] backend Makefile patch
This patch cleans up backend/Makefile a little bit, and prevents it from
relinking the backend binary when no changes have been made.
Subject: [HACKERS] abort failed transaction patch
This patch allows you to end a transaction that has failed on an error
using the 'ABORT' statement without generating another error message.
(By default you get an error unless you use 'END' to terminate the
transaction, which has already been aborted anyway.)
The following patch to src/backend/libpq/pqpacket.c provides additional
checking for bad packet length data. It was tested with the Linux telnet
client, with netcat using the numbers.txt and by dumping random numbers
into the port.
Patch by: Alvaro Martinez Echevarria <alvaro@lander.es>
The following patches add to the backend a new debugging flag -K which prints
a debug trace of all locking operations on user relations (those with oid
greater than 20000). The code is compiled only if LOCK_MGR_DEBUG is defined,
so the patch should be harmless if not explicitly enabled.
I'm using the code to trace deadlock conditions caused by application queries
using the command "$POSTMASTER -D $PGDATA -o '-d 1 -K 1'.
The patches are for version 6.0 dated 970126.
Patches from: aoki@CS.Berkeley.EDU (Paul M. Aoki)
i gave jolly my btree bulkload code a long, long time ago but never
gave him a bunch of my bugfixes. here's a diff against the 6.0
baseline.
for some reason, this code has slowed down somewhat relative to the
insertion-build code on very small tables. don't know why -- it used
to be within about 10%. anyway, here are some (highly unscientific!)
timings on a dec 3000/300 for synthetic tables with 10k, 100k and
1000k tuples (basically, 1mb, 10mb and 100mb heaps). 'c' means
clustered (pre-sorted) inputs and 'u' means unclustered (randomly
ordered) inputs. the 10k table basically fits in the buffer pool, but
the 100k and 1000k tables don't. as you can see, insertion build is
fine if you've sorted your heaps on your index key or if your heap
fits in core, but is absolutely horrible on unordered data (yes,
that's 7.5 hours to index 100mb of data...) because of the zillions of
random i/os.
if it doesn't work for you for whatever reason, you can always turn it
back off by flipping the FastBuild flag in nbtree.c. i don't have
time to maintain it.
good luck!
baseline code:
time psql -c 'create index c10 on k10 using btree (c int4_ops)' bttest
real 8.6
time psql -c 'create index u10 on k10 using btree (b int4_ops)' bttest
real 9.1
time psql -c 'create index c100 on k100 using btree (c int4_ops)' bttest
real 59.2
time psql -c 'create index u100 on k100 using btree (b int4_ops)' bttest
real 652.4
time psql -c 'create index c1000 on k1000 using btree (c int4_ops)' bttest
real 636.1
time psql -c 'create index u1000 on k1000 using btree (b int4_ops)' bttest
real 26772.9
bulkloading code:
time psql -c 'create index c10 on k10 using btree (c int4_ops)' bttest
real 11.3
time psql -c 'create index u10 on k10 using btree (b int4_ops)' bttest
real 10.4
time psql -c 'create index c100 on k100 using btree (c int4_ops)' bttest
real 59.5
time psql -c 'create index u100 on k100 using btree (b int4_ops)' bttest
real 63.5
time psql -c 'create index c1000 on k1000 using btree (c int4_ops)' bttest
real 636.9
time psql -c 'create index u1000 on k1000 using btree (b int4_ops)' bttest
real 701.0
|Subject: [PATCH] adding SYS_TIME just for fun.
|
|Hi,
|
|Whilst I was playing round with the European dates patch I noticed the sysfunc()
|that allows you to do :-
|
|create table test ( da date);
|insert into test values (SYS_DATE);
|
|and have the current system date inserted.
|
|So I thought it would be nice to have the SYS_TIME facility too.
|
|I've cloned the function and changed a few things and there you have it,
|you can now do:
|
|create table test2 ( ti time);
|insert into test2 values (SYS_TIME);
The first patch changes the behavior of aclcheck for groups. Currently an user
can access a table only if he has the required permission for ALL the groups
defined for that table. With my patch he can access a table if he has the
permission for ONE of the groups, which seems to me a more useful thing.
If you think this should be the correct behavior of the acl group check feel
free to remove the #ifdef, if not please add a commented line to config.h.
2. IndexScanableOperand now uses match_indexkey_operand
instead of equal_indexkey_var (if we have some index on attribute X
then we shouldn't use it for 'where some_func(X) OP CONST').
/usr/include/limits.h (which quiets the costsize.c warnings)...under
FreeBSD, /usr/include/limits.h *includes* machine/limits.h, while under
Solaris, there is no such things as /usr/include/machine...
Problem with Solaris pointed out by Mark Wahl
1. New flag - BM_JUST_DIRTIED - added for BufferDesc;
2. All data "dirtiers" (WriteBuffer and WriteNoReleaseBuffer)
set this flag (and BM_DIRTY too);
3. All data "flushers" (FlushBuffer, BufferSync and BufferReplace)
turn this flag off just before calling smgr[blind]write/smgrflush
and check this flag after flushing buffer: if it turned ON then
BM_DIRTY will stay ON.
