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 to
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 s
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
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 inpu
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 : #
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
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 pgda
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 vs
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 beha
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 f
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
"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
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 accu
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 conta
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 pg_attribut
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
PostgreSQL?
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 IMM
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 does
--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, regard
> > 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;
;
set enable_seqscan=true;
..
--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
act
--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
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
--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 t
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
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 sho
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 somethi
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 defini
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 1
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:
> > http://www.osdl.org/plm-cgi/plm
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_info&patch_id=4065
I took a peek at the first sparse re
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
--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
> 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 PRO
> 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 in
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 d
>
> 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 reas
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);
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, to
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 this_g
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;
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 broadcast)--
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_info&patch_id=4065
On Wed, Jan 12, 2005 at 02:18:36PM -0800, Mark Wong wrote:
> Hi,
>
> Just wondering if anyone find
=?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. Fil
> 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 broadc
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
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 4
./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.
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 m
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
# PATH=/opt/SUNWspro/bin/:/opt/sfw/bin:$PATH:/usr/
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 dat
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 ex
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 con
Bruce Momjian 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.
> Yep, that was
Tom Lane wrote:
> Bruce Momjian 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 deletion is old
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 regi
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:
pgsql-hackers@postgre
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 wrote:
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 to
-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
> -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 i
61 matches
Mail list logo