On Sat, Mar 04, 2006 at 12:08:52PM +0530, Md.Abdul Aziz wrote:
> I am a presently working on a module which enhances postgre to
> store audio files,while storing the aduido file in the databese i used
> liod,now the problem is i am able to unlink but still the data is
> present in the post
Hi,
I am a presently working on a module which enhances postgre to
store audio files,while storing the aduido file in the databese i used
liod,now the problem is i am able to unlink but still the data is
present in the postgre database.can some one suggest me how to delete (not
unlink) large
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> On 3/3/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I find the whole idea pretty ugly myself.
> why? if i can ask? you didn't seem upset with that in the thread
What's bugging me about it is that the proposed syntax wedges a bunch
of index-access-metho
On 3/3/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> > I'm trying to extend the CREATE INDEX statement with a fillfactor
> > clause.
>
> Um, are you aware that a patch for that was already submitted?
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> I find the whole idea
Jim C. Nasby wrote:
> At the risk of editorializing...
>
> * Allow for tables with more than a certain percent of free space to
> force new tuple allocation in the last few pages to come only from the
> FSM (prefering the earliest pages), with the intention of allowing the
> table to shrink
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Greg Stark)
wrote:
> Are you sure that "Temporary Resident Visa" is what you need?
> Isn't the regular visa people get called just a "Guest Visa"?
That's possible too... It is probably a good idea to contact a local
Canadian embassy
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] ("Zeugswetter Andreas
DCP SD") would write:
>> > But what about index clearing? When do you scan each index?
>>
>> At the end of each iteration (or earlier, depending on
>> maintenance_work_mem). So for each iteration you would need
>>
On Fri, Mar 03, 2006 at 08:47:41PM -0600, Jim C. Nasby wrote:
> You have a URL for where in the docs it says that? Sounds like it needs
> to be updated to include TRUNCATE.
http://www.postgresql.org/docs/7.4/static/explicit-locking.html#LOCKING-TABLES
It doesn't say that only the listed commands
You have a URL for where in the docs it says that? Sounds like it needs
to be updated to include TRUNCATE.
On Wed, Mar 01, 2006 at 03:55:26PM -0800, [EMAIL PROTECTED] wrote:
> This may be a newbie question, but according to the 7.4 docs, an ACCESS
> EXCLUSIVE lock is only acquired by the ALTER TAB
On Fri, Mar 03, 2006 at 11:37:00AM -0500, Tom Lane wrote:
> Bruce and I were discussing this the other day; it'd be pretty easy to
> make plain VACUUM start a fresh transaction immediately after it
> finishes a scan heap/clean indexes/clean heap cycle. The infrastructure
> for this (in particular,
On Fri, Mar 03, 2006 at 04:14:41PM +0100, Csaba Nagy wrote:
> > Ewe. How expensive is scanning an index compared to the heap? Does
> > anyone have figure on that in terms of I/O and time?
>
> See this post for an example:
> http://archives.postgresql.org/pgsql-performance/2006-02/msg00416.php
>
On Thu, Mar 02, 2006 at 03:19:46PM +0100, Martijn van Oosterhout wrote:
> Note, for this purpose you don't need to keep a bit per page. The
> OS I/O system will load 64k+ (8+ pages) in one go so one bit per 8
> pages would be sufficient.
AFAIK that's entirely dependant on the filesystem and how it
I'm interested in such a discussion, at least informally. I'd probably
even sit politely and listen to a presentation ;-)
Jim C. Nasby wrote:
On Fri, Mar 03, 2006 at 07:50:51AM -0800, Luke Lonergan wrote:
Peter,
I'm asking our performance lead, Ayush Parashar, to develop a talk proposal
tha
On Thu, Mar 02, 2006 at 10:05:28AM -0500, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > ??hel kenal p??eval, N, 2006-03-02 kell 09:53, kirjutas Zeugswetter
> > Andreas DCP SD:
> >> Ok, we cannot reuse a dead tuple. Maybe we can reuse the space of a dead
> >> tuple by reducing the
Tom Lane wrote:
"Matthew T. O'Connor" writes:
That patch is a step forward if it's deemed OK by the powers that be.
However, autovacuum would still need to be taught to handle simultaneous
vacuums. I suppose that in the interim, you could disable autovacuum
for the problematic queue tabl
On Mar 4, 2006, at 9:22 , Tom Lane wrote:
If we did this then RI checks would no longer be subvertible by
rules or
user triggers. Although I've been heard to argue that that's a
feature,
I think the majority of people feel it's a bug, and wouldn't be
sorry to
see it go.
Just to check,
"Matthew T. O'Connor" writes:
> That patch is a step forward if it's deemed OK by the powers that be.
> However, autovacuum would still need to be taught to handle simultaneous
> vacuums. I suppose that in the interim, you could disable autovacuum
> for the problematic queue table and have cr
On Fri, 3 Mar 2006, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Fri, 3 Mar 2006, Tom Lane wrote:
> >> BTW, I had another thought about this: if we go this way, then the plans
> >> associated with RI check queries would essentially always be trivial
> >> index lookups (for ev
Csaba Nagy wrote:
So he rather needs Hannu Krosing's patch for simultaneous vacuum ...
Well, I guess that would be a good solution to the "queue table"
problem. The problem is that I can't deploy that patch on our production
systems without being fairly sure it won't corrupt any data... an
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Fri, 3 Mar 2006, Tom Lane wrote:
>> BTW, I had another thought about this: if we go this way, then the plans
>> associated with RI check queries would essentially always be trivial
>> index lookups (for everything except RI_Initial_Check).
> Would we
On Fri, 3 Mar 2006, Tom Lane wrote:
> BTW, I had another thought about this: if we go this way, then the plans
> associated with RI check queries would essentially always be trivial
> index lookups (for everything except RI_Initial_Check). It'd be within
> the realm of feasibility to throw away
BTW, I had another thought about this: if we go this way, then the plans
associated with RI check queries would essentially always be trivial
index lookups (for everything except RI_Initial_Check). It'd be within
the realm of feasibility to throw away the current cached-plan RI
infrastructure and
[EMAIL PROTECTED] writes:
> I'm trying to extend the CREATE INDEX statement with a fillfactor
> clause.
Um, are you aware that a patch for that was already submitted?
http://momjian.postgresql.org/cgi-bin/pgpatches
I find the whole idea pretty ugly myself.
regards, tom la
On Fri, Mar 03, 2006 at 07:50:51AM -0800, Luke Lonergan wrote:
> Peter,
>
> I'm asking our performance lead, Ayush Parashar, to develop a talk proposal
> that will discuss performance of Postgres, including enhancements like the
> on-disk bitmap index, sort improvements, etc. We'd also like to di
George Weaver <[EMAIL PROTECTED]> writes:
> For pgxs, it concatentates the libdir with "/pgxs/src/makefiles/pgxs.mk" so
> its looking for "C:/Program
> Files/PostgreSQL/8.1/lib/pgxs/src/makefiles/pgxs.mk" which doesn't exist.
> ...
> If I made the entire package from source and installed it, wou
At the risk of editorializing...
* Allow for tables with more than a certain percent of free space to
force new tuple allocation in the last few pages to come only from the
FSM (prefering the earliest pages), with the intention of allowing the
table to shrink
I also believe there's also a s
- Original Message -
From: "Tom Lane"
If you're on Windows this probably means that GetShortPathName() is
failing. I'm not sure what conditions cause that, exactly. It might be
a good idea if we fixed pg_config to print out the error code rather
than just silently failing.
I think
If this would be accepted I might actually be able to accomplish this.
Maybe. :) But having a TODO wouldn't be a bad idea as well...
Would this require 2 new fields in pg_attribute, or is there a better
way to store the thresholds? I'm thinking that each field would need two
special values; 0 for
Mark Dilger writes:
> I have had the same concern, though never any hard evidence of a
> problem. If the C++ functions are wrapped with "extern C", and all
> exceptions caught (perhaps converted into error numbers which are then
> returned from the wrapper functions to the plain-C calling functio
Charles F. I. Savage wrote:
> Hi everyone,
>
> I've been able to successfully build server extension using Visual
> Studio 2005 for Windows Postgresql 8.1. However, it took a few tweaks
> which I thought I should document (maybe these issues could be fixed in
> future postgresql versions?):
S
On Fri, Mar 03, 2006 at 07:14:45PM -0200, [EMAIL PROTECTED] wrote:
> Hi,
>
> I'm trying to extend the CREATE INDEX statement with a fillfactor clause. In
> Gram.y, I did this:
> I had to add a new field into IndexStmt (unsigned int fillfactor). Everything
> is fine after parsing except that I c
[EMAIL PROTECTED] wrote:
Hi,
I'm trying to extend the CREATE INDEX statement with a fillfactor clause. In
Gram.y, I did this:
IndexStmt: CREATE index_opt_unique INDEX index_name ON qualified_name
access_method_clause '(' index_params ')' fillfactor_clause where_clause
Hi,
I'm trying to extend the CREATE INDEX statement with a fillfactor clause. In
Gram.y, I did this:
IndexStmt: CREATE index_opt_unique INDEX index_name ON qualified_name
access_method_clause '(' index_params ')' fillfactor_clause where_clause
{
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Andrew Dunstan wrote:
>>> Speaking of parsers, did anyone else notice that gcc in its latest
>>> release has ripped out the bison based parser for C and Objective-C in
>>> favor of a hand cut RD parser?
>>
>> Yeah, I did. I w
On Thu, Mar 02, 2006 at 08:41:20PM -0500, Tom Lane wrote:
> elein <[EMAIL PROTECTED]> writes:
> > ... What I'm saying is that the opclass needs to be
> > an option to PRIMARY KEY and FOREIGN KEY--
>
> PRIMARY KEY and UNIQUE, you mean.
>
> This was brought up before, but I remain less than excite
Attached is the new patch. To summarize:
- new function justify_interval(interval)
- modified function justify_hours(interval)
- modified function justify_days(interval)
These functions are defined to meet the requirements as discussed in this
thread. Specifically:
- justify_hours m
Alvaro Herrera wrote:
> Andrew Dunstan wrote:
> > Speaking of parsers, did anyone else notice that gcc in its latest
> > release has ripped out the bison based parser for C and Objective-C in
> > favor of a hand cut RD parser?
>
> Yeah, I did. I wonder what sort of effort they went to write th
Andrew Dunstan wrote:
> Stephan Szabo wrote:
>
> >On Fri, 3 Mar 2006, Tom Lane wrote:
> >
> >>The reason I'm hesitant to add a bunch more cross-type operators is
> >>mainly that we have too darn many operators named "=" already. I've
> >>seen in recent profiling tests that it's taking the parser
Stephan Szabo wrote:
On Fri, 3 Mar 2006, Tom Lane wrote:
The reason I'm hesitant to add a bunch more cross-type operators is
mainly that we have too darn many operators named "=" already. I've
seen in recent profiling tests that it's taking the parser a noticeable
amount of time to decide
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian writes:
Tom Lane wrote:
What's your point? The script fails anyway if that bit doesn't work.
Is 'id' better than what we have now if 'id' isn't widely supported?
I'm repeating myself, but: what's your point?
On Fri, 3 Mar 2006, Tom Lane wrote:
> The reason I'm hesitant to add a bunch more cross-type operators is
> mainly that we have too darn many operators named "=" already. I've
> seen in recent profiling tests that it's taking the parser a noticeable
> amount of time to decide which one is meant.
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> What's your point? The script fails anyway if that bit doesn't work.
>
> > Is 'id' better than what we have now if 'id' isn't widely supported?
>
> I'm repeating myself, but: what's your point? 'id' exists on Linux,
> and the scr
Bruce Momjian writes:
> Tom Lane wrote:
>> What's your point? The script fails anyway if that bit doesn't work.
> Is 'id' better than what we have now if 'id' isn't widely supported?
I'm repeating myself, but: what's your point? 'id' exists on Linux,
and the script fails (in the worst possible
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian writes:
> Tom Lane wrote:
>> (I'm not finding it right now, but I'm pretty sure that the SUS
>> specifies that numeric userid == 0 for superuser, whereas "root" is
>> not
>> required to be the name, so this would be more correct anyway.)
> C
On Fri, Mar 03, 2006 at 01:00:59PM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > (I'm not finding it right now, but I'm pretty sure that the SUS
> > specifies that numeric userid == 0 for superuser, whereas "root" is not
> > required to be the name, so this would be more correct anyway.)
The R
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I'd argue that this case makes sense in a purely theoretical sense,
> numeric(8,0) references int is a sensible operation (when you don't take
> into account specific PostgreSQL limitations) and it's required by spec,
> but I agree that promotion on the P
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> (I'm not finding it right now, but I'm pretty sure that the SUS
> >> specifies that numeric userid == 0 for superuser, whereas "root" is not
> >> required to be the name, so this would be more correct anyway.)
>
> > Can we assume 'i
Hi all,
thanks for the feedback. I updated the patch now.
Alvaro Herrera [2006-02-25 13:47 -0300]:
> > I improved the patch now to only ignore TABLE DATA for existing tables
> > if '-X ignore-existing-tables' is specified. I also updated the
> > documentation.
>
> Is this really an appropiate de
Bruce Momjian writes:
> Tom Lane wrote:
>> (I'm not finding it right now, but I'm pretty sure that the SUS
>> specifies that numeric userid == 0 for superuser, whereas "root" is not
>> required to be the name, so this would be more correct anyway.)
> Can we assume 'id' is on all unix systems?
Wh
Tom Lane wrote:
My concern about how nicely libstdc++ will play in the backend
environment still stands though.
I have had the same concern, though never any hard evidence of a problem. If
the C++ functions are wrapped with "extern C", and all exceptions caught
(perhaps converted into error
On Fri, 3 Mar 2006, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > There's a bit of difference between not encouraging it and disallowing it
> > entirely, but I'm willing to buy that argument. I do think that numeric
> > reference int needs to be allowed though, and I thought th
Tom Lane wrote:
> Bruce Momjian writes:
> > Chris said he did:
> >> Well all I did to fix it on FreeBSD was to remove the '-o "$LOGNAME" =
> >> 'root'' bit...
> > so I figured the patch would help, no?
>
> No, because there's no good reason to suppose that $USER wouldn't be set.
But if USER is s
Bruce Momjian writes:
> Chris said he did:
>> Well all I did to fix it on FreeBSD was to remove the '-o "$LOGNAME" =
>> 'root'' bit...
> so I figured the patch would help, no?
No, because there's no good reason to suppose that $USER wouldn't be set.
I think we should remove that entire code bloc
Stephan Szabo <[EMAIL PROTECTED]> writes:
> There's a bit of difference between not encouraging it and disallowing it
> entirely, but I'm willing to buy that argument. I do think that numeric
> reference int needs to be allowed though, and I thought that's also
> currently not there (although int
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Christopher Browne wrote:
>
> > http://www.cic.gc.ca/english/visit/letter.html
> > Letter of Invitation for Countries Whose Citizens Require a
> > Temporary Resident Visa to Enter Canada
>
> Wow, this is a great deal of burden that for sure I did
> > I got the impression that Csaba is looking more for "multiple
> > simultaneous vacuum" more than the partial vacuum.
>
> So he rather needs Hannu Krosing's patch for simultaneous vacuum ...
Well, I guess that would be a good solution to the "queue table"
problem. The problem is that I can't
Tom Lane wrote:
> Bruce Momjian writes:
> > I applied the attached patch to CVS HEAD and 8.1.X. It looks at LOGNAME
> > only if USER is not set.
>
> > ! if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ]
>
> > ! # only check $LOGNAME if $USER is not set
> > ! if [ "$USER" = 'root' -o \( ! "$USER"
Bruce Momjian writes:
> I applied the attached patch to CVS HEAD and 8.1.X. It looks at LOGNAME
> only if USER is not set.
> ! if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ]
> ! # only check $LOGNAME if $USER is not set
> ! if [ "$USER" = 'root' -o \( ! "$USER" -a "$LOGNAME" = 'root' \) ]
Br
On Fri, 3 Mar 2006, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Thu, 2 Mar 2006, Tom Lane wrote:
> >> 1. If the index opclass contains an exact operator for the case
> >> "PKtype = FKtype", use that operator.
>
> > Is this rule to read explicitly naming '=' or just the item
"Craig A. James" <[EMAIL PROTECTED]> writes:
> So now my question is: Can I somehow add other directories/libraries
> to those that Postgres uses?
This is not a Postgres problem, it's a dynamic-linker problem, and
I don't believe there is a different dynamic linker for C++ than C.
Your problem is
Matthew T. O'Connor wrote:
> Alvaro Herrera wrote:
> >Csaba Nagy wrote:
> >
> >>Now when the queue tables get 1000 times dead space compared to their
> >>normal size, I get performance problems. So tweaking vacuum cost delay
> >>doesn't buy me anything, as not vacuum per se is the performance
> >
Christopher Kings-Lynne wrote:
> >> if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ]
> >>
> >> Always fails because even tho $USER is set to 'pgsql' when su'ed,
> >> $LOGNAME is still root.
> >>
> >> This is on FreeBSD 4.9
> >
> > It seems to work on Linux; apparently there are different behaviors o
Alvaro Herrera wrote:
Csaba Nagy wrote:
Now when the queue tables get 1000 times dead space compared to their
normal size, I get performance problems. So tweaking vacuum cost delay
doesn't buy me anything, as not vacuum per se is the performance
problem, it's long run time for big tables is.
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > So for you it would certainly help a lot to be able to vacuum the first
> > X pages of the big table, stop, release locks, create new transaction,
> > continue with the next X pages, lather, rinse, repeat.
>
> > This is perfectly doa
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> So for you it would certainly help a lot to be able to vacuum the first
> X pages of the big table, stop, release locks, create new transaction,
> continue with the next X pages, lather, rinse, repeat.
> This is perfectly doable, it only needs enough mo
Zeugswetter Andreas DCP SD wrote:
>
> > > But what about index clearing? When do you scan each index?
> >
> > At the end of each iteration (or earlier, depending on
> > maintenance_work_mem). So for each iteration you would need
> > to scan the indexes.
> >
> > Maybe we could make maintenanc
> > But what about index clearing? When do you scan each index?
>
> At the end of each iteration (or earlier, depending on
> maintenance_work_mem). So for each iteration you would need
> to scan the indexes.
>
> Maybe we could make maintenance_work_mem be the deciding
> factor; after scanni
On Fri, Mar 03, 2006 at 07:46:06AM -0800, Craig A. James wrote:
> Thanks for your answers -- see below.
>
> Based on Peter's and Tom's replies regarding C++, I think you've answered
> my question: I should be able to do this without static linking. But the
> Postgres linker uses the C (not the
I think we can safely say that it is not :-)
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: 03 March 2006 15:41
To: Magnus Hagander
Cc: Hughes, James; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Initdb on Windows 2003
Magnus Hagander wrote:
>
>
>
>>Ha
Peter,
I'm asking our performance lead, Ayush Parashar, to develop a talk proposal
that will discuss performance of Postgres, including enhancements like the
on-disk bitmap index, sort improvements, etc. We'd also like to discuss the
business intelligence use-cases and where parallelism is applic
Peter Eisentraut wrote:
Unfortunately, we're also using a second library (OpenBabel) that is
written in C++. A good portion of the code I've written is a wrapper
layer that hides the C++ objects and presents a simple C wrapper that
works for Postgres.
I suggest if you want to get any concrete
Magnus Hagander wrote:
Have raised a helpdesk ticket with Microsoft, see if they can
shed any light on the problem.
Sounds good - since you can reproduce it with a simple commandline, they
should at least accept touching the case ;-)
In any case, since dir > nul fails, I think
> -Original Message-
> From: George Weaver [mailto:[EMAIL PROTECTED]
> Sent: 03 March 2006 14:55
> To: Dave Page
> Cc: Thomas Hallgren; pgsql-hackers@postgresql.org;
> [EMAIL PROTECTED]; Michael Fuhr
> Subject: Re: [HACKERS] [NOVICE] pg_config --pgxs
>
>
> From: "Dave Page"
> Sent:
> I did run filemon but did not get anything from it :( Yes I
> disabled all anti-virus software, no difference made.
Even more interesting. Do you have any other filter drivers that you
know of? SOme kind of quota stuff or so perhaps?
Oh, and if the bug is in the AV filter driver it's often not
> Ewe. How expensive is scanning an index compared to the heap? Does
> anyone have figure on that in terms of I/O and time?
See this post for an example:
http://archives.postgresql.org/pgsql-performance/2006-02/msg00416.php
For my 200 million table, scanning the pk index took ~ 4 hours. And the
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Csaba Nagy wrote:
> > >
> > > > Now when the queue tables get 1000 times dead space compared to their
> > > > normal size, I get performance problems. So tweaking vacuum cost delay
> > > > doesn't buy me anything, as not
On Fri, Mar 03, 2006 at 11:40:40AM -0300, Alvaro Herrera wrote:
> Csaba Nagy wrote:
>
> > Now when the queue tables get 1000 times dead space compared to their
> > normal size, I get performance problems. So tweaking vacuum cost delay
> > doesn't buy me anything, as not vacuum per se is the perfor
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Csaba Nagy wrote:
> >
> > > Now when the queue tables get 1000 times dead space compared to their
> > > normal size, I get performance problems. So tweaking vacuum cost delay
> > > doesn't buy me anything, as not vacuum per se is the performance
> >
Alvaro Herrera wrote:
> Csaba Nagy wrote:
>
> > Now when the queue tables get 1000 times dead space compared to their
> > normal size, I get performance problems. So tweaking vacuum cost delay
> > doesn't buy me anything, as not vacuum per se is the performance
> > problem, it's long run time for
From: "Dave Page"
Sent: Friday, March 03, 2006 8:24 AM
It might be that short filenames are disabled - George, what's the value
of the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisab
le8dot3NameCreation
Hi Dave;
The value is 0. Does that mean shor
Csaba Nagy wrote:
> > Wow, this is a great deal of burden that for sure I didn't have to do
> > last time :-( Not sure why, maybe the laws changed or something. It is
> > crystal clear that I have to do it this time however.
>
> I think you're overreacting guys... I would first try and go to the
Lukas Smith <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think that's the wrong place. transformGroupClause is the right
>> place. It already does some hacking to try to make the GROUP BY
>> semantics match ORDER BY, but it doesn't think to try reordering
>> the GROUP BY items.
> Does it
Csaba Nagy wrote:
> Now when the queue tables get 1000 times dead space compared to their
> normal size, I get performance problems. So tweaking vacuum cost delay
> doesn't buy me anything, as not vacuum per se is the performance
> problem, it's long run time for big tables is.
So for you it woul
I did run filemon but did not get anything from it :( Yes I disabled all
anti-virus software, no difference made.
Have raised a helpdesk ticket with Microsoft, see if they can shed any
light on the problem.
James
-Original Message-
From: Magnus Hagander [mailto:[EMAIL PROTECTED]
Sent:
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Thomas Hallgren
> Sent: 03 March 2006 14:18
> To: George Weaver
> Cc: Michael Fuhr; [EMAIL PROTECTED];
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [NOVICE] pg_config --pgxs
>
> Georg
George Weaver wrote:
On March 2 Tom Lane wrote:
If you're on Windows this probably means that GetShortPathName() is
failing. I'm not sure what conditions cause that, exactly. It might be
a good idea if we fixed pg_config to print out the error code rather
than just silently failing.
Hi Tom
> Wow, this is a great deal of burden that for sure I didn't have to do
> last time :-( Not sure why, maybe the laws changed or something. It is
> crystal clear that I have to do it this time however.
I think you're overreacting guys... I would first try and go to the
nearest Canadian embassy an
> All
>
> I have determined what is causing the failure. It appears
> that the stdout & stderr redirection to nul produces the
> "Access is Denied."
> message. This is happening even if I type "dir >nul" at the
> command prompt! I assume that this re-direction in PostgreSQL
> is done when star
Christopher Browne wrote:
> Here should be the authoritative information:
>
> http://www.cic.gc.ca/english/visit/visas.html
> Countries/Territories Requiring Visas
>
> http://www.cic.gc.ca/english/visit/letter.html
> Letter of Invitation for Countries Whose Citizens Require a
> Temporary
On March 2 Tom Lane wrote:
If you're on Windows this probably means that GetShortPathName() is
failing. I'm not sure what conditions cause that, exactly. It might be
a good idea if we fixed pg_config to print out the error code rather
than just silently failing.
Hi Tom,
I am using Windows
> Are you running 8.1? If so, you can use autovacuum and set per table
> thresholds (read vacuum aggressivly) and per table cost delay settings
> so that the performance impact is minimal. If you have tried 8.1
> autovacuum and found it unhelpful, I would be curious to find out why.
Yes, I'm
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
A simple hack might help with a subset of this problem, though. For
queries with both ORDER BY and GROUP BY clauses, we can sort the
grouping columns according to their position in the ORDER BY list. So,
given a query like:
SELECT a, b,
92 matches
Mail list logo
