Hi!
I use postgres6.1. Before install new version I do not make dump_all, but
I move /usr/local/pgsql to /usr/local/pgsql_bk. After that I successfuly
install new version to /usr/local/pgsql. But now I need some data from old
postgres. I try to do this:
% kill postmaster_id
% mv
On Wednesday 03 December 2003 13:59, Mark Kirkwood wrote:
How about:
Implement a function estimated_count that can be used instead of
count. It could use something like the algorithm in
src/backend/commands/analyze.c to get a reasonably accurate psuedo count
quickly.
The advantage of this
Anand, VJ (MED, GEMS-IT) kirjutas K, 03.12.2003 kell 18:18:
Hello:
I am trying to find out, how is the B-tree index implemented for
multiple columns? does Postgres, just
concatenate the columns ---
Yes.
if this is the case, then how is the
search performed? Also, does
Joe Conway wrote:
We (mostly Bruce, Tom, Peter, and I) have been having a discussion on
the PATCHES list regarding some new functionality related to read-only
GUC variables. The net result is pasted at the bottom of this post. Here
is a link to the discussion:
Marc G. Fournier wrote:
block_size - int
Shows size of a disk block
integer_datetimes - bool
Datetimes are integer based
max_function_args - int
Shows the maximum number of function arguments
max_identifier_length - int
Shows the maximum identifier length
On Thu, 04 Dec 2003 03:35:49 +0100
Magnus Naeslund(t) [EMAIL PROTECTED] wrote:
Well this just isn't the case.
There is no printout in kernel logs/dmesg (as it would be if the
kernel killed it in an OOM situation).
I have 1 GB of RAM, and 1.5 GB of swap (swap never touched).
Do you have
Magnus Naeslund(t) [EMAIL PROTECTED] writes:
Doug McNaught wrote:
Linux is probably killing your process because it (the kernel) is low
on memory. Unfortunately, this happens more often with older versions
of the kernel. Add more RAM/swap or figure out how to make your query
use less
On Thu, Dec 04, 2003 at 06:53:40AM -0500, Bruce Momjian wrote:
Joe Conway wrote:
The main open question at this point is the name for the block_size
variable. Peter favors block_size, Bruce favors page_size, Tom
hasn't taken a position on that specific issue. Does anyone have and
On Wed, 3 Dec 2003, Stephan Szabo wrote:
The locale settings depend on LC_* at initdb time only. When the
postmaster starts it sets the locale based on the stored values from
initdb, not on the current environment.
With an SQL_ASCII database being accessed from a client with
client_encoding
E.Rodichev wrote:
On Wed, 3 Dec 2003, Stephan Szabo wrote:
The locale settings depend on LC_* at initdb time only. When the
postmaster starts it sets the locale based on the stored values from
initdb, not on the current environment.
With an SQL_ASCII database being accessed from a client with
Bruce Momjian wrote:
Marc G. Fournier wrote:
I'd go with block_size ...
True, page size usually references virtual memory pages, so it is
related to virtual memory mapping. Block size is much more related to
on-disk storage, true. The only reason I was leaning toward page is
that it is possible
On Thu, 4 Dec 2003, E.Rodichev wrote:
On Wed, 3 Dec 2003, Stephan Szabo wrote:
The locale settings depend on LC_* at initdb time only. When the
postmaster starts it sets the locale based on the stored values from
initdb, not on the current environment.
With an SQL_ASCII database
hi :
pg_stat_user_tables store the
n_tup_ins,n_tup_upd,n_tup_del information, and those information is very
useful.
Icheck the pg_stat_user_indexes table, but there are no
such information.
can i get such information in other way ?
or system catalog does not store such information
!
or
Would it be (is it?) possible to add timestamp to the log
messages put out by postgresql? I've got several databases
running in an environment where users have this annoying
habit of coming up to me with (Oh yes, three days ago around
4pm our instrument had trouble writing to database X.).
run it through syslog?
On Thu, 4 Dec 2003, Steve Wampler wrote:
Would it be (is it?) possible to add timestamp to the log
messages put out by postgresql? I've got several databases
running in an environment where users have this annoying
habit of coming up to me with (Oh yes, three days
Bruce Momjian [EMAIL PROTECTED] writes:
I hate to reply to this because I have already cast my vote, but
block_size does not report the size of a disk block. It reports the
size of a PostgreSQL block/page. Disk blocks are almost always 512
bytes in size.
Perhaps then neither block nor page
Marc G. Fournier wrote:
run it through syslog?
or set log_timestamp = true in postgresql.conf ?
On Thu, 4 Dec 2003, Steve Wampler wrote:
Would it be (is it?) possible to add timestamp to the log
messages put out by postgresql? I've got several databases
running in an environment where
On Thu, 2003-12-04 at 09:52, Andrew Dunstan wrote:
Marc G. Fournier wrote:
run it through syslog?
or set log_timestamp = true in postgresql.conf ?
Thanks - for some reason I was assuming that only applied
to logging connections. Should have tried it...
Thanks again!
--
Steve Wampler
I have an idea for what I think may be a very simple optimization for postgres
to make. I would like to try my hand at implementing it, but the last time I
tried I apparently started off in the wrong direction.
In the following query, the sort step is completely unnecessary. The order is
Lamar Owen wrote:
On Tuesday 02 December 2003 06:29 pm, Gaetano Mendola wrote:
Lamar Owen wrote:
You need to specify that you are building for Red Hat 9 on the command
I'll try.
Ok.
I did it on a RHAS 2.1
and I get:
make[3]: Leaving directory
On Thursday 04 December 2003 02:29 pm, Gaetano Mendola wrote:
I did it on a RHAS 2.1
and I get:
For RHAS 2.1 you need to tell it that you are running Red Hat 7.x (--define
'build7x 1') Which I think disables the plperl build (but don't quote me on
that).
I'm working on making this
Jeff wrote:
Do you have any system monitoring scripts that may be killing it as it
may look like a runaway process?
We've had this happen to us before. You tend to forget about things like
that.
This got me thinking, and i rechecked all possibilities.
It turned out that we changed rlimit
Greg Stark kirjutas N, 04.12.2003 kell 19:55:
I have an idea for what I think may be a very simple optimization for postgres
to make. I would like to try my hand at implementing it, but the last time I
tried I apparently started off in the wrong direction.
In the following query, the sort
Hannu Krosing kirjutas N, 04.12.2003 kell 23:01:
Where should I be looking in the code?
Try to find where the modified query is tested for. It's probably be
inside the optimizer, as index scan + no sort is not always faster than
seq scan + sort, as shown by the same query after vacuum
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
while changing a column from base255 encoded text (all except null byte) to
bytea, I found the following bug in Postgresql's LIKE operator with indexes
(it follows a more detailed description then my old mails in -bugs and
- -general, including
Alvar Freude wrote:
while changing a column from base255 encoded text (all except null byte) to
bytea, I found the following bug in Postgresql's LIKE operator with indexes
(it follows a more detailed description then my old mails in -bugs and
- -general, including the proof of the bug):
Apparently
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
- -- Joe Conway [EMAIL PROTECTED] wrote:
Apparently you never read my reply to you all the way to the bottom. I
said:
oh, sorry, I understand your mail wrong!
I understand it in this way, that you are not sure that there is something
buggy,
Alvar Freude wrote:
I'm sorry, but after reading the desciption of bugs again I realised that
according to the list desciption bugs is the wrong one und hackers the
right; so, after debugging my code two days I'm now sure that there is
something wrong with Postgres. Normally such Problems are in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
- -- Joe Conway [EMAIL PROTECTED] wrote:
I understand the root cause,
but am still trying to figure out what the right solution is. It may
take another day or so due to other things I have going on (like my job
;-)).
:-)
If you need some
Greg Stark [EMAIL PROTECTED] writes:
At what point in the process would it make sense to check for this?
You'd need to mess with the code that generates pathkeys describing
the sort ordering of index scans --- read about pathkeys in
src/backend/optimizer/README. As Hannu notes nearby, the
30 matches
Mail list logo
