Of course the question did you vacuum (better, did you analyze) is
annoying, just as the requirement to analyze is annoying in the first
place, but unless someone designs a better query planner it
will have to do. The reason why we always ask that question first is
that people
*very* slow, due to seq scan on
20 million entries, which is a test setup up to now)
Perennial first question: did you VACUUM ANALYZE?
Can there, or could there, be a notion of rule based optimization of
queries in PostgreSQL? The not using index problem is probably the
most
The http link to the snapshots no longer works on
www.ca.postgresql.org/ftpsite.
If you could correct that I would greatly appreciate it :-)
Also this link only works on some of the mirror sites,
it would be great if all of them would have it (Germany works, Austria
does not).
I think a
I am quite sure that all AIX Versions accept the CLOBBER method,
thus I ask you to apply the following patch, to make it work.
CLOBBER does not work with AIX5L, nor CHANGE_ARGV. (SETPROCTITLE,
PSTAT and PS_STRINGS can not be used since AIX5L does not have
appropreate header files).
BTW, still I'm getting the stucking backends. New info: a snapshot
dated on 10/3 works fine.
I allways have trouble with those different date formats. Do you
mean, that the problem is fixed as of 3. October, or that an old
snapshot from 10. March still worked ?
Of course the
Andreas, have you tried CVS tip lately on AIX? What's your results?
All 77 ok, no hangs, with make check on single CPU AIX 4.3.2.
Only problem on AIX is, that the argv[0] stuff does not work anymore
(I think since we don't exec() anymore), which is rather annoying.
Andreas
Only problem on AIX is, that the argv[0] stuff does not work anymore
(I think since we don't exec() anymore), which is rather annoying.
Hmm, perhaps we are selecting the wrong PS_STRINGS method for AIX?
Please look at src/backend/utils/misc/ps_status.c and see if one of
the other
Thomas Lockhart [EMAIL PROTECTED] writes:
Perhaps it'd be a better idea for the option of a freebie
conversion
to be checked earlier, say immediately after we discover there is
no
exact match for the function name and input type. Thomas, what do
you
think?
We *really* need that
You are attacking here two things:
a) schemas, which should be done in 7.3,
Is imho something different alltogether. (I know we have two opposed
views here)
thus multiple databases on same host would be unnecessary.
I disagree :-)
b) connections to remote host' databases, which is
- shell script ---
for i in 32 64 128 256 512 1024 2048 4096 8192
do
psql -c explain analyze select liketest(a,'aaa') from
(select substring('very_long_text' from 0 for $i) as a) as a test
done
- shell script ---
I don't think your
Tatsuo Ishii [EMAIL PROTECTED] writes:
... There seems some problems existing in the
implementation. Considering REGEX is not so slow, maybe we should
employ the same design as REGEX. i.e. using wide charcters, not
multibyte streams...
Seems like a good thing to put on the to-do
Would this seem a reasonable thing to do? Does anyone rely on COPY
FROM causing an ERROR on duplicate input?
Yes. This change will not be acceptable unless it's made an optional
(and not default, IMHO, though perhaps that's negotiable) feature of
COPY.
The implementation might be
... cs(3)
Seems same as AIX 4?
Yes, identical.
Hmm, does anyone want to produce new s_lock code for AIX that uses
compare_and_swap? But I'm not sure that's the problem here.
I did once, but performance was worse, so I discarded it.
Since AIX 5 still has it, I see no reason to change it.
The O_DIRECT flag has been added to open(2) and fcntl(2). Specifying
this
flag for open files will attempt to minimize the cache effects of
reading
and writing.
I wonder if using this for WAL would be good.
Not before the code is not optimized to write more than the current 8k
to
the
As you can see, psql reconnect as any user if the password is same
as
foo. Of course this is due to the careless password setting, but I
think it's better to prompt ANY TIME the user tries to switch to
another user.
I'm not sure. A few users have voiced concerns about this before,
I experienced that UNIONs in 7.1.1 are rather slow:
tir=# explain (select nev from cikk) union (select
tevekenyseg from log);
NOTICE: QUERY PLAN:
Unique (cost=667.63..687.18 rows=782 width=12)
- Sort (cost=667.63..667.63 rows=7817 width=12)
- Append (cost=0.00..162.17
For bytea, follow this rule: to escape a null character, use
this:
'\\0'. To escape a backslash, use this: ''.
Can anybody explain in technical terms why this is implemented
so inconveniently ?
Since bytea is probably not very common among users yet
we could imho still change it to
Current sources don't compile on AIX with xlc compiler because of the
combined (and inconsistent ? or compiler bug) use of extern and static
for the datetktbl in datetime.c.
header unconditionally has:
extern datetkn datetktbl[];
source has:
static datetkn datetktbl[] = {
The usual
Hiroshi wrote:
There could be DELETE operations for the tuple
from other backends also and the TID may disappear.
Because FULL VACUUM couldn't run while the cursor
is open, it could neither move nor remove the tuple
but I'm not sure if the new VACUUM could
I don't understand why you object the idea giving PostgreSQL the
ability to turn off the locale support in configuration/compile
time. In that way, there's no inconveniences for many users.
I don't mind at all the ability to turn it off. My point is that the
compile time is the wrong
DBMS should be independent from the OS settings as far as
possible especially in the handling of data. Currently we
could hardly judge if we are running on a locale or not from
the dbms POV and it doesn't seem a dbms kind of thing in the
first place. I'm a dbms guy not an OS guy and really
I would object even if there's such a way.
People in Japan have hardly noticed that the strange
behabior is due to the strange locale(LC_COLLATE).
I don't think we should design our systems in a way that
inconveniences
many users because some users are using broken operating systems.
Face it, everything has locale support these day. PostgreSQL is one
of
the few packages that even has it as an option to turn it off. Users
of
binary packages of PostgreSQL are all invariably faced with locale
features. So it's not like sudden unasked-for locale support is going
to
be a
If your solution is short-lived, your change would be not
only useless but also harmful. So I expect locale-aware
people to confirm that we are in the right direction.
I am a bit confused here. We have tinkered with LIKE indexing at
least a
year. Now that a solution is found that
Some other databases have the notion of a ROWID which uniquely
identifies a row
within a table. OID can be used for that, but it means if you use it,
you must
limit the size of your whole database system.
Imho that is getting it all wrong. OID is *not* a suitable substitute
for other
db's
There could be DELETE operations for the tuple
from other backends also and the TID may disappear.
Because FULL VACUUM couldn't run while the cursor
is open, it could neither move nor remove the tuple
but I'm not sure if the new VACUUM could remove
the deleted tuple and
test=# create index myindex on accounts(aid) where bid 0;
Hmm ? Am I reading correctly ? a restriction that is on a field,
that
is not in the index ? Does that make sense ?
Yes it does, and in fact it's one of the more important applications
of
partial indexes. It's the only way
Even more to the point, those typical installations do not want
exclusive-locked VACUUM. Haven't you paid any attention to the user
complaints we've been hearing for the last N years? People want a
nonexclusive VACUUM (or no VACUUM at all, but that's not a choice we
can
offer them now.)
It seems to me, I guess and others too, that the OID mechanism should
be on a
per table basis. That way OIDs are much more likely to be unique, and
TRUNCATE
on a table should reset it's OID counter to zero.
Seems to me, that this would be no different than a performance improved
version
of
201 - 229 of 229 matches
Mail list logo
