Would anybody object to a patch to update psql's tab completion for
SET/RESET/SHOW to include everything that SHOW shows for a superuser?
I count about 65 variables that SHOW shows that are missing from
pgsql_variables in tab-complete.c. Does the list intentionally
omit certain variables? The
We already have a TODO for this:
* Add transaction_timestamp(), statement_timestamp(),
clock_timestamp()
functionality
I like the idea of having a function for statement start time. I
think I'll incorporate it into my patch.
The suggested naming convention in the TODO
On Fri, Aug 12, 2005 at 10:27:16PM -0400, Bruce Momjian wrote:
Where are we going with this patch? It doesn't test specific OS's known
to fail.
I hoped people more familiar with the problem would tune it...
Here is updated patch where I test specifically
'openbsd*|freebsd*' instead of
Hi all.
I've been reported memory limit hits
during a postgis index construction
(GiST index).
The indexed tuples are about 425 millions.
The index key is a box2d object (4*sizeof(float)).
The machine has 4 Gb of RAM, and operations are
peaked at ~2.4 Gb of usage.
Is there a way to detect where
Missing info for the report:
win32
postgresql 8.0.3
maintenance_work_mem 512
btree index on oid works fine
--strk;
On Sat, Aug 13, 2005 at 01:12:30PM +0200, [EMAIL PROTECTED] wrote:
Hi all.
I've been reported memory limit hits
during a postgis index
[Please CC any replies, thanks]
Hi,
I got this nice error, and according to Tom Lane[1]:
Depending on what PG version you're using (which you did not say,
naughty naughty) there are paths in interactive query entry that
might try to execute datatype input functions before setting the
query
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm working on the promised DROP OWNED patch, and just noticed that it
needs modifications to the Grant/Revoke machinery that are too invasive
to consider for 8.1; the problem is that ExecuteGrantStmt takes textual
names for objects and grantees, and
Michael Fuhr wrote:
Would anybody object to a patch to update psql's tab completion for
SET/RESET/SHOW to include everything that SHOW shows for a superuser?
I count about 65 variables that SHOW shows that are missing from
pgsql_variables in tab-complete.c. Does the list intentionally
omit
Tom Lane [EMAIL PROTECTED] wrote:[EMAIL PROTECTED]
William ZHANG [EMAIL PROTECTED] writes:
Why not change the option createuser to superuser,
Backwards compatibility with existing dump files.
or do something to make is easier to understand?
See
Bruce Momjian wrote:
I am not sure it was reported to you but this has been corrected:
I saw Tom's fixes on -committers, thank you.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
FYI, with the patch queue shrinking, it is time to consider a date for
beta. The current plan is to start beta in 7-10 days, so possible dates
are August 19 or 22.
We will need to have all major patches addressed, the release notes
done, and the major documentation usable.
--
Bruce Momjian
On Sat, Aug 13, 2005 at 10:33:55AM -0400, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I count about 65 variables that SHOW shows that are missing from
pgsql_variables in tab-complete.c. Does the list intentionally
omit certain variables?
It's intentional that the tab
Hi Hackers,
I wasn't paying attention to the mailing lists (or the release notes)
when dollar-quoting was developed, and I stumbled across it in the
documentation today.
I just wanted to say, nice work!
I've definitely known the pain of doubling my single quotes ad
nauseum, and this is a
I am wondering if is worth managing which items should be displayed or
not, and if we should just give up and display them all. The GUC system
is just too dynamic.
---
Michael Fuhr wrote:
On Sat, Aug 13, 2005 at
Bruce Momjian pgman@candle.pha.pa.us writes:
I am wondering if is worth managing which items should be displayed or
not, and if we should just give up and display them all. The GUC system
is just too dynamic.
Not sure. I count 98 GUC variables currently listed in tab-complete.c,
and 162 rows
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I am wondering if is worth managing which items should be displayed or
not, and if we should just give up and display them all. The GUC system
is just too dynamic.
Not sure. I count 98 GUC variables currently listed in
On Sat, Aug 13, 2005 at 09:25:34AM -0600, Michael Fuhr wrote:
Here's the list I came up with -- variables that SHOW shows that
aren't in psql's completion list.
Here's the list broken down by context:
PGC_USERSET
autocommit
check_function_bodies
debug_assertions
escape_string_warning
On Sat, Aug 13, 2005 at 11:39:59AM -0400, Tom Lane wrote:
I count 98 GUC variables currently listed in tab-complete.c,
and 162 rows in pg_settings.
Is 162 a typo or are you working on something that hasn't been
committed yet? I see 161 in the latest code.
template1=# SELECT count(*) FROM
Martijn van Oosterhout kleptog@svana.org writes:
- Is there a way to detect if a snapshot has been started and creating
one if there hasn't. I've seen the snapshot related functions but I
don't feel comfortable sticking them in my type input function just to
fix this. Is it safe?
This would
Michael Fuhr [EMAIL PROTECTED] writes:
Is 162 a typo or are you working on something that hasn't been
committed yet? I see 161 in the latest code.
Uh, I get 162 ... and no I don't have any uncommitted changes ATM.
The last change I see in guc.c was two days ago (latest autovacuum
additions),
On Sat, Aug 13, 2005 at 12:36:42PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
- Is there a way to detect if a snapshot has been started and creating
one if there hasn't. I've seen the snapshot related functions but I
don't feel comfortable sticking them in my
On Sat, Aug 13, 2005 at 12:41:51PM -0400, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
Is 162 a typo or are you working on something that hasn't been
committed yet? I see 161 in the latest code.
Uh, I get 162 ... and no I don't have any uncommitted changes ATM.
I found the
Tom Lane [EMAIL PROTECTED] writes:
Michael Fuhr [EMAIL PROTECTED] writes:
Is 162 a typo or are you working on something that hasn't been
committed yet? I see 161 in the latest code.
Uh, I get 162 ... and no I don't have any uncommitted changes ATM.
Oh, I bet I know what it is: I built with
Martijn van Oosterhout kleptog@svana.org writes:
I'm a bit concerned about the possible side-effects of this on existing
behavior, though. In particular constructs like
'now'::timestamp
would change behavior subtly.
It's a good idea, eventually. All it would do is change the time it's
On Sat, Aug 13, 2005 at 11:04:18AM -0600, Michael Fuhr wrote:
I had removed --enable-cassert from my configure script while doing
some performance tests and never put it back (I had noticed that
VACUUM was quite slow on that box and found that it was due to the
assertion checks).
BTW, here
Hiroki Kataoka [EMAIL PROTECTED] writes:
This small patch improves the performance of INSERT and UPDATE. By my
machine, these changes raised the performance about 5%~10% in pgbench.
BTW, in profiling the backend I've never seen PageAddItem take more than
about 1% of the runtime, and in
Michael Fuhr [EMAIL PROTECTED] writes:
BTW, here are the results of those tests: a VACUUM ANALYZE of
template1 without --enable-cassert takes about 830ms on my box.
With --enable-cassert it takes about 24200ms, regardless of the
debug_assertions setting.
I believe that in current sources, the
Tom Lane wrote:
Hiroki Kataoka [EMAIL PROTECTED] writes:
This small patch improves the performance of INSERT and UPDATE. By my
machine, these changes raised the performance about 5%~10% in pgbench.
BTW, in profiling the backend I've never seen PageAddItem take more than
about 1% of the
A little while ago I rather rashly opined that we could extend the
buildfarm to do (optional) performance testing. After thinking about it
for some time I now think that might not be such a good idea. We can
certainly leverage a lot of the technology used and experience gained in
building
Bruce Momjian pgman@candle.pha.pa.us writes:
Qingqing Zhou wrote:
Things could get worse because the whole database cluster may stop working
and waiting for the buffer the bgwriter is working on, but bgwriter is
waiting for (by the deadloop in pgunlink) those postgres'es to move on (so
that
On 8/14/05, Bruce Momjian pgman@candle.pha.pa.us wrote:
Brendan Jurd wrote:
We already have a TODO for this:
* Add transaction_timestamp(), statement_timestamp(),
clock_timestamp()
functionality
I like the idea of having a function for statement start time.
On Sun, Aug 14, 2005 at 05:51:16AM +1000, Brendan Jurd wrote:
Regarding the statement_timestamp() ... if the entire query path is
parser - rewriter - planner/optimiser - executor, what point in
that path would be considered the true start of the statement? I
would assume that it's right at
Brendan Jurd [EMAIL PROTECTED] writes:
Regarding the statement_timestamp() ... if the entire query path is
parser - rewriter - planner/optimiser - executor, what point in
that path would be considered the true start of the statement?
IIRC, what we actually intended that to mean is the time of
Andrew Dunstan [EMAIL PROTECTED] writes:
Incidentally, use of a different SCM system might well make
constructing test sets more simple. Imagine, say, in SVN, you would
create a branch called test-set--mm-dd or some such, make your
changes there, add a test script under some well known
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Incidentally, use of a different SCM system might well make
constructing test sets more simple. Imagine, say, in SVN, you would
create a branch called test-set--mm-dd or some such, make your
changes there, add a test script
On Sat, Aug 13, 2005 at 10:09:35AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm working on the promised DROP OWNED patch, and just noticed that it
needs modifications to the Grant/Revoke machinery that are too invasive
to consider for 8.1; the problem is that
Tom Lane [EMAIL PROTECTED] writes:
However, if you favor a no thought required approach, listing 'em
all is certainly the path of least resistance. I'm just dubious that
that maximizes the usefulness of tab completion.
I'm not sure if you're interested, but my 2c speaking as a user would be
I am thinking the proper term for the first column of pg_stat_file() is
size, not length.
test= select * from pg_stat_file('.');
length | atime | mtime |
ctime | isdir
38 matches
Mail list logo
