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 e
-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
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
-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:
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,
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 th
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 vac
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 so
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 polici
Tom Lane <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (David Fetter) writes:
>> While PL/Perl is great, it's not available everywhere, and I'd like
>> to be able to grab atoms from a regex match in, say, a SELECT. Is
>> there some way to get access to them?
>
> There's a three-parameter variant
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 automati
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 `/usr/src/redhat/BUILD/postgresql-7.4/src/pl/tc
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
already
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!
--
Ste
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 u
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"
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 d
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.").
Hav
hi :
pg_stat_user_tables store the
n_tup_ins,n_tup_upd,n_tup_del information, and those information is very
useful.
I check 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 t
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 da
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 t
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
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_enc
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
"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
>> u
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 y
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
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:
> http://archives.postgresq
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,
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 advanta
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 /usr/local
31 matches
Mail list logo
