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
++-
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 wou
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 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 scrip
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 wel
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
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 rig
On 8/14/05, Bruce Momjian 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. I
>
Bruce Momjian 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 they could clos
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 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
>>>ab
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
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
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
Martijn van Oosterhout 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
> evaluat
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 bu
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
On Sat, Aug 13, 2005 at 12:36:42PM -0400, Tom Lane wrote:
> Martijn van Oosterhout 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 fu
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
Martijn van Oosterhout 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 be a pretty bad
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 pg_
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_warnin
Tom Lane wrote:
> Bruce Momjian 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,
> an
Bruce Momjian 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 in pg_settings. So
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 10:33:55A
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 fantast
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 ta
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
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
s
"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
> http://developer.po
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
>
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 completion not list every single variable;
I think if it did, it wou
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, a
[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
> que
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 constru
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
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 '*bsd*
37 matches
Mail list logo
