-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Cramer
Sent: 12 January 2005 22:38
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] looking for rh9 rpms for pgadmin v 1.2
Hi,
Is there any intent to build these rpm's ? Who is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Wed, 12 Jan 2005, Dave Cramer wrote:
Is there any intent to build these rpm's ? Who is responsible for this ?
I remember a guy that was working on it. HE pushed me several times to get
the spec file :) I've sent him at last, bur dont't remember
The fundamental problem is that you can't do it without adding at least
16 bytes, probably 20, to the size of an index tuple header. That would
double the physical size of an index on a simple column (eg an integer
or timestamp). The extra I/O costs and extra maintenance costs are
unattractive
OK, I built the rpm. where do you want me to send it?
BTW, there is a bug in configure. If ssl is not configured in the
server (which is easy to do in rh9), the configure script does not
correctly configure the makefile. It still tries to build pgadmin with
ssl support.
Dave
Dave Page
Hi Dave,
Thanks very much - please email it to me and I'll upload
it.
Re the bug, that one was noted previously and I believe
Adam is working on it.
Regards, Dave.
From: Dave Cramer [mailto:[EMAIL PROTECTED]
Sent: 13 January 2005 11:23To: Dave PageCc:
Bruce Momjian wrote:
FWIW, I've seen several apps that use .txt for config files, but I can't
think of an example right now. Most don't though - .cfg or .conf is
probably most common. Except for the majority of windows programs that
don't use config files - they use the registry. But I
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Ah, right, I missed the connection. Hmm ... that's sort of the inverse
of the killed tuple optimization we put in a release or two back,
where an index tuple is marked as definitely dead once it's committed
dead and the
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
The ugly part of this is that clearing the bit is not like setting a
hint bit, ie it's not okay if we lose that change. Therefore, each
bit-clearing would have to be WAL-logged. This is a big part of my
concern about the cost.
Kevin Brown wrote:
Bruce Momjian wrote:
FWIW, I've seen several apps that use .txt for config files, but I can't
think of an example right now. Most don't though - .cfg or .conf is
probably most common. Except for the majority of windows programs that
don't use config files - they
On Thu, 13 Jan 2005 10:29:16 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Wrong. The WAL recovery environment is not capable of executing
arbitrary user-defined functions, therefore it cannot compute index
entries on its own. The *only* way we can do this is if the WAL
record stream tells exactly
D'Arcy J.M. Cain wrote:
I'm not sure why everyone wants to push this into the database anyway.
If I need to know the count of something, I am probably in a better
position to decide what and how than the database can ever do. For
example, I recently had to track balances for certificates in a
i have encountered some problems with sun studio 9 (version 8 always
worked for me).
obviously it does not like my linker flags ...
when running the following script I get ...
#!/bin/sh
LD_LIBRARY_PATH=/opt/sfw/lib:/usr/local/lib:$LD_LIBRARY_PATH
#
I have no problems with the patch ...
On Thu, 13 Jan 2005, Bruce Momjian wrote:
Kevin Brown wrote:
Bruce Momjian wrote:
FWIW, I've seen several apps that use .txt for config files, but I can't
think of an example right now. Most don't though - .cfg or .conf is
probably most common. Except for the
./configure --enable-debug --with-perl
==
All 96 tests passed.
==
uname -a
Linux richard 2.6.5-7.111.19-smp #1 SMP Fri Dec 10 15:10:58 UTC 2004
x86_64 x86_64 x86_64 GNU/Linux
--
Brad Nicholson
Database Administrator, Afilias Canada Corp.
Hi!
Here's an odd thing. I use a partial index on a table:
group_data
CREATE TABLE group_data (
this_group_id integer NOT NULL,
group_id integer
-- ...
);
create index foo on group_data(this_group_id) where group_id is null;
there are approx 1 million tuples where this_group_id=46, but only
Hello,
I have small piece of code for testing speed of stored procedures. First
time used its for compare mysql5 and postgresql. One year ago (feb.2004)
was PostgreSQL much faster than mysql5. Now I was surprised. Mysql was
faster. Mysql's developers did some work, but plpgsql is slowly than
create index foo on group_data(this_group_id) where group_id is null;
Try this instead;
create index foo on group_data(this_group_id) where nullvalue(group_id);
And
Select * from group_data where this_group_id = 46 and nullvalue(group_id);
... John
---(end of
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
tuptoaster.c, line 966: member can not have variably modified type: data
We've seen that before. Apparently there are some versions of Sun's
compiler that are too stupid to reduce this constant expression to a
constant. File a
We've also started automating sparse analyses in our PLM tool, which
will show an error and warning count. Here's an example:
http://www.osdl.org/plm-cgi/plm?module=patch_infopatch_id=4065
On Wed, Jan 12, 2005 at 02:18:36PM -0800, Mark Wong wrote:
Hi,
Just wondering if anyone finds
Palle Girgensohn [EMAIL PROTECTED] writes:
On 7.4.5, it uses the index, but on 8.0rc5, it does not:
Have you ANALYZEd the 8.0 table lately? Those rowcount estimates look
mighty far off.
regards, tom lane
---(end of
Pavel Stehule [EMAIL PROTECTED] writes:
CREATE OR REPLACE FUNCTION delitel(int, int) RETURNS int AS '
DECLARE a integer; b integer;
BEGIN a := $1; b := $2;
WHILE a b LOOP
IF a b THEN a := a - b; ELSE b := b - a; END IF;
END LOOP;
RETURN a;
END; ' LANGUAGE plpgsql;
And?
(ie,
Yes, they are analyzed and vacuumed.
How do you mean they look far off? The data in the two db:s where not
identical in the example i sent. With identical data in both 7.4.5 and
8.0.0rc5 (both freshly pg_restored and vacuum analyzed), 7.4.5 used the
index, and for 8.0.0rc5, when I add the
Pavel Stehule [EMAIL PROTECTED] writes:
And?
(ie, what test case are you talking about?)
This test is function for searching max factor. It is speaking only about
quality of interpret an language. I would ask why?
So I can replicate your test.
regards, tom lane
Thanks, but the behaviour seems identical. :(
/Palle
--On fredag, januari 14, 2005 07.37.46 +1100 John Hansen
[EMAIL PROTECTED] wrote:
create index foo on group_data(this_group_id) where group_id is null;
Try this instead;
create index foo on group_data(this_group_id) where nullvalue(group_id);
And?
(ie, what test case are you talking about?)
regards, tom lane
This test is function for searching max factor. It is speaking only about
quality of interpret an language. I would ask why? If I need solve fast
this task I can write C function. What is reason
Palle Girgensohn [EMAIL PROTECTED] writes:
How do you mean they look far off?
Seq Scan on group_data (cost=0.00..47544.43 rows=114164 width=43) (actual
time=114.015..1334.479 rows=4 loops=1)
114164 estimated vs 4 actual rows is pretty far off. Perhaps something
skewed about the data
Thanks, but the behaviour seems identical. :(
odd tho, that I was never able to get null values indexed (index was
never used) unless I used this approach
h
on the other hand, just realised youre not actually indexing null
values,... here, is null is the qualifier for the partial
If you want, I can send you the data.
if you can make available for download somewhere, a dump of the schema
and data, I won't mind having a go at it...
... John
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL
--On torsdag, januari 13, 2005 17.03.41 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Palle Girgensohn [EMAIL PROTECTED] writes:
How do you mean they look far off?
Seq Scan on group_data (cost=0.00..47544.43 rows=114164 width=43)
(actual time=114.015..1334.479 rows=4 loops=1)
114164 estimated vs
On Thu, Jan 13, 2005 at 05:05:00PM -0500, Tom Lane wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
And?
(ie, what test case are you talking about?)
This test is function for searching max factor. It is speaking only about
quality of interpret an language. I would ask why?
So I can
On Thu, Jan 13, 2005 at 01:31:36PM -0800, Mark Wong wrote:
We've also started automating sparse analyses in our PLM tool, which
will show an error and warning count. Here's an example:
http://www.osdl.org/plm-cgi/plm?module=patch_infopatch_id=4065
I took a peek at the first sparse
On Thu, Jan 13, 2005 at 08:06:23PM -0300, Alvaro Herrera wrote:
On Thu, Jan 13, 2005 at 01:31:36PM -0800, Mark Wong wrote:
We've also started automating sparse analyses in our PLM tool, which
will show an error and warning count. Here's an example:
I don't thing so differention on speed depends on compilation or other
options. I compile 8.0 and 7.4.6 from source today. I didn't use any
option for configure. But the difference is too big for optimalizations.
[EMAIL PROTECTED] root]# uname -a
Linux stehule.fsv.cvut.cz 2.6.4 #1 SMP Mon Mar
Michael Fuhr [EMAIL PROTECTED] writes:
SELECT delitel(100, 1);
Mean times over the last five of six runs on my poor 500MHz FreeBSD
4.11-PRERELEASE box:
6741 ms 7.4.6 (from FreeBSD ports collection)
14427 ms 8.0.0rc5 (from CVS source)
When I add IMMUTABLE to the function definition,
Michael Fuhr wrote:
On Thu, Jan 13, 2005 at 05:05:00PM -0500, Tom Lane wrote:
SELECT delitel(100, 1);
Mean times over the last five of six runs on my poor 500MHz FreeBSD
4.11-PRERELEASE box:
6741 ms 7.4.6 (from FreeBSD ports collection)
14427 ms 8.0.0rc5 (from CVS source)
Looks like
Palle Girgensohn [EMAIL PROTECTED] writes:
--On torsdag, januari 13, 2005 18.18.37 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
So there's something nuts about the statistics in this case.
On looking into it, it's the same old issue of not having column
correlation statistics. pg_stats shows that
I wrote:
I thought of a fairly miserable hack, which relies on the fact that 8.0
does know how to accumulate statistics on functional indexes:
Never mind, it turns out that doesn't work the way I thought. It's
actually falling back to a default estimate :-(. I still think it'd
be a good idea
--On torsdag, januari 13, 2005 18.55.11 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Palle Girgensohn [EMAIL PROTECTED] writes:
--On torsdag, januari 13, 2005 18.18.37 -0500 Tom Lane
[EMAIL PROTECTED] wrote:
So there's something nuts about the statistics in this case.
On looking into it, it's the
Palle Girgensohn [EMAIL PROTECTED] writes:
Trying all this out, I realize that on 7.4.5, I can sometimes get different
results after `vacuum analyze' vs. a plain `analyze' (again, not exactly
the same data, and I cannot reproduce this on the other machine with the
data I sent you). It does
--On torsdag, januari 13, 2005 19.44.57 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Palle Girgensohn [EMAIL PROTECTED] writes:
Trying all this out, I realize that on 7.4.5, I can sometimes get
different results after `vacuum analyze' vs. a plain `analyze' (again,
not exactly the same data, and I
--On torsdag, januari 13, 2005 19.32.38 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
I wrote:
I thought of a fairly miserable hack, which relies on the fact that 8.0
does know how to accumulate statistics on functional indexes:
Never mind, it turns out that doesn't work the way I thought. It's
Dunno if you're desperate enough to try that ... but it does seem to work.
if yo're going to hack anyway, then why not just simply tell the planner
that you know better and that it should use the index, regardles of the
stats collected?
set enable_seqscan=false;
your original query here;
set
--On fredag, januari 14, 2005 11.52.38 +1100 John Hansen
[EMAIL PROTECTED] wrote:
Dunno if you're desperate enough to try that ... but it does seem to
work.
if yo're going to hack anyway, then why not just simply tell the planner
that you know better and that it should use the index, regardles
Palle Girgensohn [EMAIL PROTECTED] writes:
Interesting. Yes, I might be that desperate, actually. As desperate as 30 s
vs 30 ms can get me... :)
And this one would actually accumulate stats alright? Looks kinda hairy to
me. It's not really a partial index anymore, but I guess that doesn't
On Thu, Jan 13, 2005 at 06:25:10PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
6741 ms 7.4.6 (from FreeBSD ports collection)
14427 ms 8.0.0rc5 (from CVS source)
When I add IMMUTABLE to the function definition, I get much closer
times.
Indeed -- adding IMMUTABLE
Folks,
As this came up in a work situation, I was wondering a little bit
about the top-k issue. Right now, top-k is implemented (most easily,
I think) via a SELECT with a LIMIT and no OFFSET. 3 questions arise
from this.
1. Are there currently any optimizations specific to top-k in
Did some searching, and figured/concluded that things are pretty much
hosed ... the last backup is from June (clients machine, not ours), but
before I suggest going back to that backup, I want to make sure that I
haven't overlooked anything ...
What the client did was a 'delete from
Has anybody tried porting PostgreSQL to a stack machine or
accumulator machine?
More specifically, how specialized is the source code in PostgreSQL,
would it be possible to port the PostgreSQL source to a older version of
GCC? There are some stack and accumulator based machines that contain
Benjamin Arai wrote:
Has anybody tried porting PostgreSQL to a stack machine or
accumulator machine?
More specifically, how specialized is the source code in PostgreSQL,
would it be possible to port the PostgreSQL source to a older version of
GCC? There are some stack and accumulator
Marc G. Fournier [EMAIL PROTECTED] writes:
What the client did was a 'delete from pg_attribute where ... ' ...
[ blink... ] Well, that sort of thing is definitely a candidate for the
Darwin Award, but what exactly was the WHERE clause?
The database is a 7.4.2 one ... my first thought was one
On Thu, 13 Jan 2005, David Fetter wrote:
3. What kinds of top-k optimizations might (eventually) be included
in PostgreSQL?
See the TODO item:
Allow ORDER BY ... LIMIT 1 to select high/low value without sort or index
using a sequential scan for highest/lowest values
If only one value
Palle Girgensohn [EMAIL PROTECTED] writes:
No surprise. vacuum analyze produces an exact total row count, whereas
analyze can only produce an approximate total row count (since it only
samples the table rather than groveling over every row). Sometimes the
approximate count will be far enough
John Hansen [EMAIL PROTECTED] writes:
Thanks, but the behaviour seems identical. :(
odd tho, that I was never able to get null values indexed (index was
never used) unless I used this approach
You're mixing up the indexed column with the where clause of a partial index.
They behave
Marc G. Fournier wrote:
What the client did was a 'delete from pg_attribute where ... ' ...
The database is a 7.4.2 one ... my first thought was one of the older
standbys ... rebuild the schema and move the data files into place over
top of that ... but of course, 7.3 and beyond are OID based
Marc,
In case you don't work out a better way to sort this, I can reproduce
and fix the error 'catalog is missing n attribute(s) for relid 16396'
caused by directly deleting (part of) pg_attribute:
Setup :
$ initdb
$ pg_ctl start
$ createdb test
Backup :
$ pg_ctl stop
$ tar -czvf pgdata.tar.gz
Simon,
On Wed, 12 Jan 2005 at 08:23, Simon Riggs wrote:
Not sure what is going on here: why is SUSE not listed on the supported
platforms list? (still)
...is it because Reinhard seems resistant
why do you think so?
(after private conversation) to the idea of submitting a formal port
Hello!
My name is Nurlan Mukhanov.
3 years ago I have made CSS file for PostgreSQL docs
reading. Can anybody include it in mainstream?
==CUT START=
BODY { font-family : Tahoma; font-size : 8pt; color :
#33; background: #FF; }
A:LINK { color :
Hello sir,
We have developed an web application in ASP.Net with back end as POSTGreSQL Version 7.4 for Linux, which works fine without any issues. Recently we had tested the same application with POSTGreSQL Version 8.0 for Windows, there we found lots of issues like if we input more than
They probaly released the informix database patents.
This is pertinent to us as several of them were interesting
implementations of things like the function manager.
--elein
On Tue, Jan 11, 2005 at 08:04:48AM -0800, Darcy Buskermolen wrote:
IBM has just announced they are waving all rights and
Tom,
On Wed, 12 Jan 2005 at 03:53, Tom Lane wrote:
...or is it because his postings to ANNOUNCE that the port to SUSE
have gone unnoticed by those that compile the supported platforms
list?
If he insists on posting such routine stuff to pgsql-announce, he
should not be too surprised
David Fetter wrote:
Folks,
As this came up in a work situation, I was wondering a little bit
about the top-k issue. Right now, top-k is implemented (most easily,
I think) via a SELECT with a LIMIT and no OFFSET. 3 questions arise
from this.
I think the simplest LIMIT query doesn't make it easy
61 matches
Mail list logo
