Saturday, July 5, 2008

[HACKERS] PATCH: CITEXT 2.0 v2

On Jun 27, 2008, at 18:22, David E. Wheeler wrote:

> Please find attached a patch adding a locale-aware, case-insensitive
> text type, called citext, as a contrib module.

Here is a new version of the patch, with the following changes:

* Fixed formatting to be more like core.
* Added appropriate NEGATORs to operators.
* Removed NEGATOR from the || operator.
* Added hash index function and operator class.
* The = operator now supports HASHES and MERGES.
* citext_cmp and citextcmp both return int32.
* Changed // comments to /* comments */.
* Added test confirming láska'::citext <> 'laská'::citext.
* A few other organizational, formatting, and pasto fixes.
* Updated the FAQ entry on case-insensitive queries to recommend
citext (it would, of course, need to be translated).

Stuff I was asked about but didn't change:

* citext_cmp() still uses varstr_cmp() instead of strncmp(). When I
tried the latter, everything seemed to be equivalent.
* citext_smaller() and citext_larger() don't have memory leaks, says
Tom, so I added no calls to PG_FREE_IF_COPY().

Thank you everyone for your feedback and suggestions!

Best,

David

Re: [PERFORM] How much work_mem to configure...

On Sat, Jul 5, 2008 at 5:24 AM, Jessica Richard <rjessil@yahoo.com> wrote:
> How can I tell if my work_mem configuration is enough to support all
> Postgres user activities on the server I am managing?
>
> Where do I find the indication if the number is lower than needed.

You kinda have to do some math with fudge factors involved. As
work_mem gets smaller, sorts spill over to disk and get slower, and
hash_aggregate joins get avoided because they need to fit into memory.

As you increase work_mem, sorts can start happening in memory (or with
less disk writing) and larger and larger sets can have hash_agg joins
performed on them because they can fit in memory.

But there's a dark side to work_mem being too large, and that is that
you can run your machine out of free memory with too many large sorts
happening, and then the machine will slow to a crawl as it swaps out
the very thing you're trying to do in memory.

So, I tend to plan for about 1/4 of memory used for shared_buffers,
and up to 1/4 used for sorts so there's plenty of head room and the OS
to cache files, which is also important for performance. If you plan
on having 20 users accessing the database at once, then you figure
each one might on average run a query with 2 sorts, and that you'll be
using a maximum of 20*2*work_mem for those sorts etc...

If it's set to 8M, then you'd get approximately 320 Meg max used by
all the sorts flying at the same time. You can see why high work_mem
and high max_connections settings together can be dangerous. and why
pooling connections to limit the possibility of such a thing is useful
too.

Generally it's a good idea to keep it in the 4 to 16 meg range on most
machines to prevent serious issues, but if you're going to allow 100s
of connections at once, then you need to look at limiting it based on
how much memory your server has.

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PATCHES] pgbench minor fixes

Simon Riggs <simon@2ndquadrant.com> writes:
> On Sun, 2008-07-06 at 00:06 +1000, Russell Smith wrote:
>> Simon Riggs wrote:
>>> 1. -i option should run vacuum analyze only on pgbench tables, not *all*
>>> tables in database.
>
>> How does this work with custom scripts?

> I don't think we can justify vacuuming every table in the database just
> so we get any tables being used for one set of tests.

Actually your point is that the -i option wouldn't be used anyway
with a custom script ...

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [GENERAL] roll back to 8.1 for PyQt driver work-around

Scott Frankel <frankel@circlesfx.com> writes:
> Any suggestions for how best to launch one of two different versions
> of pg installed on the same machine?

> I have both 8.3 and 8.1 installed on a MacBookPro (OS X 10.5.2). I
> stopped the 8.3 postmaster using pg_ctl in order to roll back to 8.1.
> Problem is, now I can't seem to start the server using either version.

It looks like you're trying to use the same data directory for both
versions, which won't work. They're not compatible on-disk.

> When I launch 8.1 with pg_ctl, it yields a "postmaster starting"
> message; but then a status check shows that the server is not
> running. Issuing the same commands for 8.3, I get similar results.

Looking into the postmaster log file (your -l specification) might
yield some insight. pg_ctl itself doesn't really know why the
postmaster failed to start.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] CommitFest rules

Robert Treat <xzilla@users.sourceforge.net> writes:
> Hmm, looks like some of the things I was thinking about have been added
> recenelt... cool. One question I have still remains though, on the main
> developer page (http://wiki.postgresql.org/wiki/Development_information) it
> has a link to the "current commitfest", which points to september's
> commitfest page. ISTM the current commitfest is July's, since that's the one
> we're currently working on.

The meaning of "current commitfest" as used on that page is "the place
you should submit a new patch today". I agree there's a terminological
problem here, and we need to somehow distinguish that meaning from "the
commitfest we are currently trying to close out". But you are not
helping matters by trying to eliminate the distinction.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] time_stamp type

"Stephen R. van den Berg" <srb@cuci.nl> writes:
> What's the deal with this type?

It's a domain over timestamptz, as required by the SQL spec definition
of the information_schema.

postgres=# \dD information_schema.time_stamp
List of domains
Schema | Name | Type | Modifier | Check
--------------------+------------+-----------------------------+----------------------------------------------------+-------
information_schema | time_stamp | timestamp(2) with time zone | default ('now'::text)::timestamp(2) with time zone |
(1 row)

[ re-reads spec... ] Hm, actually the spec is self-contradictory here:
SQL99 20.7 saith

CREATE DOMAIN TIME_STAMP AS TIMESTAMP (2)
DEFAULT CURRENT_TIMESTAMP(2);

which appears to imply that TIME_STAMP is a domain over timestamp
*without* time zone ... but that is contradicted by the specification
that the default is CURRENT_TIMESTAMP, which yields a value *with*
time zone. (LOCALTIMESTAMP is the function that should have been
mentioned if they really meant without time zone.)

[ pokes further... ] Hmm, last year's SQL200n draft saith

CREATE DOMAIN TIME_STAMP AS TIMESTAMP(2) WITH TIME ZONE;

with no mention of a default. I do wish these people could make
up their minds.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[PERFORM] filesystem options for WAL

Hi,

Here http://www.westnet.com/~gsmith/content/postgresql/TuningPGWAL.htm I read:
"""
Combining these two, an optimal fstab for the WAL might look like this:

/dev/hda2 /var ext3 defaults,writeback,noatime 1 2
"""
Is this info accurate?

I also read on other document from the "technical documentation" that
for partitions where you have the tables and indexes is better to have
journaling and for partitions for the WAL is better to not have
journalling...

i tought it has to be the other way (tables & indices without
journalling, WAL with journalling)

--
regards,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PATCHES] [HACKERS] Solaris ident authentication using unix domain sockets

Andrew Dunstan <andrew@dunslane.net> writes:
> Robert Treat wrote:
>> Hmm... I've always been told that Solaris didn't support this because the
>> Solaris developers feel that IDENT is inherently insecure.

> We don't actually use the Ident protocol for Unix sockets on any
> platform.

Indeed. If the Solaris folk feel that getupeercred() is insecure,
they had better explain why their kernel is that broken. This is
entirely unrelated to the known shortcomings of the "ident" IP
protocol.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [pgsql-es-ayuda] como definir tablas para que las consultas sean rapidas ?

On Sat, Jul 5, 2008 at 11:53 AM, Carlos Mendez <lucas1850@gmail.com> wrote:
> PRIMARY KEY (id),
> UNIQUE(paterno,materno,nombre,fecha_nac)
>

Cada insert/update en esa tabla te va a doler... ademas de que no te
va a proteger si alguien ingresa dos veces al mismo alumno si hacemos
esto:

JAIME CASANOVA MERCHAN
Jaime CASANOVA MERCHAN
JAIME Casanova Merchan
etc...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 8: explain analyze es tu amigo

Re: [HACKERS] PATCH: CITEXT 2.0

On Jul 5, 2008, at 08:13, Tom Lane wrote:

>> Stupid question: What would the negation of || actually be? There
>> isn't one is, there?
>
> Per the docs, NEGATOR is only sensible for operators returning
> boolean.

Message received. Many thanks, Tom, as usual.

Best,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH: CITEXT 2.0

On Jul 5, 2008, at 02:58, Gregory Stark wrote:

>> do I need to worry about memory leaks in citext_eq, citext_ne,
>> citext_gt,
>> etc.,
>
> yes

Thanks.

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH: CITEXT 2.0

On Jul 5, 2008, at 02:58, Gregory Stark wrote:

>> txt = cilower( PG_GETARG_TEXT_PP(0) );
>> str = VARDATA_ANY(txt);
>>
>> result = hash_any((unsigned char *) str, VARSIZE_ANY_EXHDR(txt));
>
> I thought your data type implemented a locale dependent collation,
> not just
> a case insensitive collation. That is, does this hash agree with your
> citext_eq on strings like "foo bar" <=> "foobar" and "fooß" <=>
> "fooss" ?

CITEXT is basically intended to replace all those queries that do
`WHERE LOWER(col) = LOWER(?)` by doing it internally. That's it. It's
locale-aware to the same extent that `LOWER()` is (and that citext 1.0
is not, since it only compares ASCII characters case-insensitively).
And I expect that it does, in fact, agree with your examples, in that
all the current tests for = and <> pass:

try=# select 'foo bar' = 'foobar';
?column?
----------
f

try=# SELECT 'fooß' = 'fooss';
?column?
----------
f

> You may have to use strxfrm

In the patch against CVS HEAD, it uses str_tolower() in formatting.c.

Best,

David


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A Windows x64 port of PostgreSQL

chris wrote:
>> C++0x standards
>> committee where they finalized long long as being required to be 8
>
> AFAIK, we oughtn't care what C++ standards say, because PostgreSQL is
> implemented in C, and therefore needs to follow what the *C* standards
> say.

I agree the C++ standards should matter one bit to postgresql, but
AFAIK C99 also says "long long" is at least 64 bits too -- but if
we're talking C99, we'd be better off using whichever of int64_t
or int_least64_t or int_fast64_t we really meant anyway. Since we
don't I assume we're trying to be compatible with pre-c99 C too
which AFAICT means you can't assume much about "long long" either.
Pre-C99 you can't really count on much. I've spent time where "int"
was 20 bits; and on another platform where int was 32 bits and
long 40 bits.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[GENERAL] roll back to 8.1 for PyQt driver work-around

Hello, I just signed on the list.

Any suggestions for how best to launch one of two different versions
of pg installed on the same machine?

I have both 8.3 and 8.1 installed on a MacBookPro (OS X 10.5.2). I
stopped the 8.3 postmaster using pg_ctl in order to roll back to 8.1.
Problem is, now I can't seem to start the server using either version.

When I launch 8.1 with pg_ctl, it yields a "postmaster starting"
message; but then a status check shows that the server is not
running. Issuing the same commands for 8.3, I get similar results.

eg:

[tiento:~] postgres% /opt/local/lib/postgresql81/bin/pg_ctl start -D /
Library/PostgreSQL8/data -l /Users/Shared/pgLog/pgLog.txt
postmaster starting

[tiento:~] postgres% /opt/local/lib/postgresql81/bin/pg_ctl status -D /
Library/PostgreSQL8/data
pg_ctl: neither postmaster nor postgres running


I'm trying to roll back to version 8.1 as I've run into a bug in Qt's
QPSQL driver. I'm able to create tables and add rows of data to them;
but my model.select() statements all fail. The "This version of
PostgreSQL is not supported and may not work" message is ominous ;)

Thanks in advance!
Scott

Scott Frankel
President/VFX Supervisor
Circle-S Studios
510-339-7477 (o)
510-332-2990 (c)

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [PATCHES] [HACKERS] Solaris ident authentication using unix domain sockets

Robert Treat wrote:
> On Thursday 03 July 2008 14:01:22 Tom Lane wrote:
>
>> Garick Hamlin <ghamlin@isc.upenn.edu> writes:
>>
>>> I have a patch that I have been using to support postgresql's
>>> notion of ident authentication when using unix domain sockets on
>>> Solaris. This patch basically just adds support for using
>>> getupeercred() on Solaris so unix sockets and ident auth works just
>>> like it does on Linux and elsewhere.
>>>
>> Cool.
>>
>>
>
> Hmm... I've always been told that Solaris didn't support this because the
> Solaris developers feel that IDENT is inherently insecure. If that is more
> than just a philosphical opinion, I wonder if there should be additional
> hurdles in place to enable this on that platform. Note that isn't an
> objection from me, though I'm curious if any of the Sun guys want to chime in
> on this.
>
>


We don't actually use the Ident protocol for Unix sockets on any
platform. AIUI, this patch just implements what we do on platforms like
Linux or *BSD.

cheers

andrew

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[GENERAL] Query Problem

Hi Fellows
 
I still have problem to access my databank.It shows syntax problem,I am using VC++ 2005 with postgresql 8.3.My table name is Person and it has three column,Person ID,first name and last name (testing version).whole c++ code is
 
 
// Test_postgres.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "libpq-fe.h"
 
 
int _tmain(int argc, _TCHAR* argv[])
{
const char *conninfo;
PGconn *conn;
const char *paramtext = "server_version";
PGresult *res;
conninfo = "hostaddr = 127.0.0.1 dbname = Salman_db user = postgres password = 732047";
conn = PQconnectdb(conninfo);
if (PQstatus(conn) != CONNECTION_OK)
{
printf("Unable to establish connection: %s",
PQerrorMessage(conn));
return 1;
} else
{
 
res = PQexec(conn, "INSERT INTO public.Person VALUES (221,'Siddiqi','Umer')");
if (PQresultStatus(res) != PGRES_COMMAND_OK)
{
printf("Problem with command: %s\n", PQerrorMessage(conn));
PQclear(res);
PQfinish(conn);
return 1;
}
PQclear(res);
}
PQfinish(conn);

return 0;
}
 
It shows no relation between public and person,if i write only person ,it show ,Person doesn't exist.
 
hope, u ppl can help me.
 
Sheikh Salman Ahmed
Diplomand in Nano Struktur Technologie
Duisburg-Essen Universität
Mobile : 0049-179-9463738
Home :0049-203-3945028




Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it!

Re: [HACKERS] CommitFest rules

On Saturday 05 July 2008 18:07:46 Robert Treat wrote:
> On Thursday 03 July 2008 15:12:08 Joshua D. Drake wrote:
> > On Thu, 2008-07-03 at 20:06 +0100, Dave Page wrote:
> > > On Thu, Jul 3, 2008 at 8:02 PM, Marko Kreen <markokr@gmail.com> wrote:
> > > > On 7/3/08, Dave Page <dpage@pgadmin.org> wrote:
> > > >> it concerns me that despite it being day 3 of the July commit fest,
> > > >> people are still being advised to add new items to the wiki page.
> > > >>
> > > >> So please - new patches to the September page!
> > > >
> > > > But updates to existing patches should be ok?
> > >
> > > Yes.
> >
> > Perhaps this would be helpful:
> >
> > http://wiki.postgresql.org/wiki/CommitFest:Help
>
> Actually, I think we need to be better about linking to that and the
> various commmitfest pages within the wiki itself. Right now it's a bit
> disorienting trying to find your way around within the wiki itself....
> well, maybe I will get some time to fix that in the next couple of days.
>

Hmm, looks like some of the things I was thinking about have been added
recenelt... cool. One question I have still remains though, on the main
developer page (http://wiki.postgresql.org/wiki/Development_information) it
has a link to the "current commitfest", which points to september's
commitfest page. ISTM the current commitfest is July's, since that's the one
we're currently working on. Also, if you're looking to submit a new patch,
the July page also has a link to Septembers page, so you end up where you
need to be; but if you want to see what is currently being worked on, going
to Septembers page has no link to July's page, so you end up having to hit
the search engine to find the right page. So, I'm think that the first link
should point to whichever commitfest page is either actively being worked on,
or will be next to be worked on (the link being updated next when the July
fest closes). Any objections?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-www] News and Events moderation (again)

I've been out on holidays, resuming my chores on these lists also today.

gb.-

On Sat, Jul 5, 2008 at 4:45 PM, Dave Page <dpage@pgadmin.org> wrote:
On Sat, Jul 5, 2008 at 8:23 PM, Devrim GÃœNDÃœZ <devrim@gunduz.org> wrote:
> On Sat, 2008-07-05 at 20:16 +0100, Dave Page wrote:
>> > As I wrote you on IM 2 days before, I'm more than willing to re-take
>> > this over.
>>
>> Thanks Devrim.
>
> FWIW, I'm enjoying a holiday now, and probably I won't be able to
> moderate them until next weekend, then go on as usual.

OK - go grab a beer or three then :-p


--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www



--
Guido Barosio
-----------------------
http://www.globant.com
guido.barosio@globant.com

Re: [pgsql-www] Events moderation

On Wednesday 02 July 2008 14:29:57 Dave Page wrote:
> On Wed, Jul 2, 2008 at 5:28 PM, Joshua D. Drake <jd@commandprompt.com>
wrote:
> > On Wed, 2008-07-02 at 17:23 +0100, Dave Page wrote:
> >> JD,
> >>
> >> I've got complaints that events aren't being moderated. You
> >> volunteered to keep on top of this when I last complained that things
> >> were getting missed - is there a technical problem we need to resolve?
> >
> > Can you attach another arm without leaving a scar?
>
> No scar? What are you, man or mouse? :-p
>
> > No this is completely
> >
> > my bad and an oversight on my part. I apologize. I will be more diligent
> > in the future.
>
> Thanks :-)
>

Are nagios alerts still going to -slaves? ISTR there was some talk about
directing them to more specific emails, did that ever happen?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[GENERAL] Installation problem -- another installation is in progress

I am attempting to install the postrgresql-8.3.3-1 download on Windows Vista. When I get to the "Ready to install" dialog and click OK, I get the message "Another installation is in progress", and I need to click on cancel and end the installation -- otherwise I am in a loop. This happens even after I reboot. Any help would be greatly appreciated.

Susan


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP

On Sat, Jul 05, 2008 at 10:43:57AM +0200, Hans-Juergen Schoenig wrote:
> hello david,
>
> i did some quick testing with this wonderful patch.
> it seems there are some flaws in there still:
>
> test=# explain select count(*)
> test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL SELECT
> DISTINCT n+1 FROM t )
> test(# SELECT * FROM t WHERE n < 5000000000) as t
> test-# WHERE n < 100;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> !> \q
>
> this one will kill the planner :(
> removing the (totally stupid) distinct avoids the core dump.

Any idea why this might be happening?

> i found one more issue;
>
> -- broken: wrong result
> test=# select count(*) from ( WITH RECURSIVE t(n) AS (
> SELECT 1 UNION ALL SELECT n + 1 FROM t)
> SELECT * FROM t WHERE n < 5000000000) as t WHERE n < (
> select count(*) from ( WITH RECURSIVE t(n) AS (
> SELECT 1 UNION ALL SELECT n + 1 FROM t )
> SELECT * FROM t WHERE n < 5000000000) as t WHERE n < 100) ;
> count
> -------
> 1
> (1 row)
>
> if i am not totally wrong, this should give us a different result.

What result should it give, and what do you think is going wrong here?

> i am looking forward to see this patch in core :).

So am I :)

> it is simply wonderful ...
>
> many thanks,

Thanks go to the kind people who actually wrote the thing. I've just
been using git to keep the bit-rot off it :)

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [HACKERS] CommitFest rules

On Thursday 03 July 2008 18:16:38 Dave Page wrote:
> On Thu, Jul 3, 2008 at 10:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > "Merlin Moncure" <mmoncure@gmail.com> writes:
> >> Are you suggesting that omission of a patch on the 'fest' page means
> >> that you are bumped from the fest?
> >
> > No, if you had submitted the patch on time then the correct next step
> > is to get it added to the fest page; I don't think that should be
> > controversial. But the reviewers aren't gonna review it if it's not
> > listed on that page...
>
> Right, but the author should take some responsibility for ensuring the
> patch is listed on time. What we don't want is forgotten patches
> getting added at the last minute, right as the CommitFest manager is
> wrapping things up having got 95% of the patches reviewed and the
> other 5% in progress.
>

I think people are still working there way through the process, but it's
starting to sound like submitting a patch involves two steps from now on;
email to the list, and add your patch to the next commitfest page. Does that
sound right?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] CommitFest rules

On Thursday 03 July 2008 15:12:08 Joshua D. Drake wrote:
> On Thu, 2008-07-03 at 20:06 +0100, Dave Page wrote:
> > On Thu, Jul 3, 2008 at 8:02 PM, Marko Kreen <markokr@gmail.com> wrote:
> > > On 7/3/08, Dave Page <dpage@pgadmin.org> wrote:
> > >> it concerns me that despite it being day 3 of the July commit fest,
> > >> people are still being advised to add new items to the wiki page.
> > >>
> > >> So please - new patches to the September page!
> > >
> > > But updates to existing patches should be ok?
> >
> > Yes.
>
> Perhaps this would be helpful:
>
> http://wiki.postgresql.org/wiki/CommitFest:Help
>

Actually, I think we need to be better about linking to that and the various
commmitfest pages within the wiki itself. Right now it's a bit disorienting
trying to find your way around within the wiki itself.... well, maybe I will
get some time to fix that in the next couple of days.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [PATCHES] [HACKERS] Solaris ident authentication using unix domain sockets

On Thursday 03 July 2008 14:01:22 Tom Lane wrote:
> Garick Hamlin <ghamlin@isc.upenn.edu> writes:
> > I have a patch that I have been using to support postgresql's
> > notion of ident authentication when using unix domain sockets on
> > Solaris. This patch basically just adds support for using
> > getupeercred() on Solaris so unix sockets and ident auth works just
> > like it does on Linux and elsewhere.
>
> Cool.
>

Hmm... I've always been told that Solaris didn't support this because the
Solaris developers feel that IDENT is inherently insecure. If that is more
than just a philosphical opinion, I wonder if there should be additional
hurdles in place to enable this on that platform. Note that isn't an
objection from me, though I'm curious if any of the Sun guys want to chime in
on this.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [GENERAL] Target lists can have at most 1664 entries?

On Sat, 5 Jul 2008 08:17:37 -0700
David Fetter <david@fetter.org> wrote:

> On Wed, Jul 02, 2008 at 09:22:50AM +0200, Bjørn T Johansen wrote:
> > On Wed, 02 Jul 2008 03:04:04 -0400
> > Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > =?UTF-8?Q?Bj=C3=B8rn?= T Johansen <btj@havleik.no> writes:
> > > > What does this mean and how can it be fixed?
> > >
> > > Reduce the number of columns in your SELECTs?
> > >
> > > This whiffs to me of excruciatingly bad schema design. How could
> > > you possibly need upwards of a thousand columns in a query result?
> > > IMHO reasonable column counts are O(10), not O(bignum).
> >
> > Well, I do agree but it is not my design and a "fix" in PostgreSQL
> > would be quicker than fixing the design....
>
> That's where you're badly mistaken. Your application is completely
> broken, and trying to adjust everybody else's Postgres to accommodate
> *your* broken application is both selfish and short-sighted. It's
> selfish because you're asking others to do work they don't need to do
> just so you can avoid doing work you need to do, and it's
> short-sighted because your application is guaranteed to be broken in
> lots of other ways if it's broken this way.
>
> Fix the application, and if you can't, find another job where they're
> not being idiots. There are plenty of Postgres-related jobs out
> there.
>
> Cheers,
> David.

Actually, this discussion was finished a long time ago (we are already looking at the Hibernate config and domain modell)..
And btw, I wasn't proposing a change in PostgreSQL, only if there were some config that could be changed to accomodate this...


BTJ

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Installation problem -- another installation is in progress

I am attempting to install the postrgresql-8.3.3-1 download on Windows Vista. When I get to the "Ready to install" dialog and click OK, I get the message "Another installation is in progress", and I need to click on cancel and end the installation -- otherwise I am in a loop. This happens even after I reboot. Any help would be greatly appreciated.

Susan


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] introduction of WIP window function patch

On Sun, 2008-07-06 at 03:40 +0900, H.Harada wrote:
> Hi,
>
> 2008/7/6 Simon Riggs <simon@2ndquadrant.com>:
> >
> > On Sat, 2008-07-05 at 16:20 +0200, Martijn van Oosterhout wrote:
> >> On Sat, Jul 05, 2008 at 07:04:29PM +0900, H.Harada wrote:
> >
> >> > http://umitanuki.net/pgsql/wfv01/design.html
> >> >
> >> > The problem is, as written in the "Things to discussed" section of the
> >> > document, how you define window functions (e.g. RANK()). My idea is to
> >> > treat them as specialized functions such as SET OF functions and mark
> >> > it in pg_proc. But this doesn't resolve RANK() boundary problem.
> >>
> >> Actually, I would make RANK() and ROW_NUMBER() act more like
> >> aggregates. ISTM you have two kinds of window functions:
> >>
> >> - aggregation: a result is calculated over a set and the result copied
> >> across all the rows.
> >> - order depenadant: same as above, but the result is different for each
> >> row.
> >>
> >> I think you could make the latter work using the current aggregation
> >> setup, just by calling the final_func for each row rather than just
> >> once at the end.
> >
> > AFAICS there's no overlap between windowed aggregates and normal
> > aggregates, so we can different infrastructure for each. I like the
> > suggestion of doing it very similarly to current aggregates, but I would
> > introduce a new function hook for windowed aggregates, wfunc.
>
> I think there are two types of functions for windowed mode.
> - windowed aggregate
> this type of function is exactly same as normal aggregate. So we use
> functions that have been in pgsql already. Actually in my patch above,
> I didn't introduce any new function. This type of function includes
> simply sum(), avg(), etc. which returns same values on a partition or
> a window frame.
>
> - windowed function
> this is the NEW type of function. I guess we should add a new function
> type to pgsql. This type of function includes rank(), rank_dense(),
> row_number(), etc. Windowed functions returns different values per
> tuple.
>
> The difference between two types is if the function returns the same
> value during a partition or different values.
>
> So, windowed aggregate and normal aggregate overlap each other. How
> you know which one is that you see OVER clause in SQL just after the
> function call. When you see OVER after func(), and pg_proc says it's
> an aggregate, it's a windowed aggregate. Otherwise, it's a windowed
> function.
>
> If I misunderstood about those definitions please correct me.

Yes, I understand that and I think Martijn does also.

I've done some thinking and rooting around on this and I think I have a
different proposal for you, different to what we just discussed.

SQL2008 specifies window functions as

* rank functions
* distribution functions: percent_rank() and cume_dist()
* rownumber()
* ntile()
* lead() and lag()
* first, last and n-th value functions
* inverse distribution functions (similar to n-th value, based upon
distribution function results)

plus window aggregate functions (the normal aggregates COUNT, SUM etc)

Now looking through all of those, I don't see *any* window functions
that need access to different datatypes, or actually need to see the
values of the attributes.

The normal aggregates work with windows identically to the way they do
without windows, so no change needed there.

AFAICS we could define all of the non-aggregate window functions on the
above list *without* defining them as functions in pg_proc. That would
be a benefit because the window functions are very powerful and we'd
need to give them access to any/all tuples in the window.

So that would mean we don't provide a mechanism for user-defined
windowed aggregate functions at all. Which solves the discussion about
how to pass generic info through to them (at least long enough to get
the first implementation done).

We do already have such functions in code, e.g. greatest(). Sure they
need to be defined in code, but we don't need to come up with a generic
API for them.

If you disagree, think about how we'd implement lag() or ntile() and
what info we'd need to pass them.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-www] News and Events moderation (again)

On Sat, Jul 5, 2008 at 8:23 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
> On Sat, 2008-07-05 at 20:16 +0100, Dave Page wrote:
>> > As I wrote you on IM 2 days before, I'm more than willing to re-take
>> > this over.
>>
>> Thanks Devrim.
>
> FWIW, I'm enjoying a holiday now, and probably I won't be able to
> moderate them until next weekend, then go on as usual.

OK - go grab a beer or three then :-p


--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [pgsql-www] News and Events moderation (again)

On Sat, 2008-07-05 at 20:16 +0100, Dave Page wrote:
> > As I wrote you on IM 2 days before, I'm more than willing to re-take
> > this over.
>
> Thanks Devrim.

FWIW, I'm enjoying a holiday now, and probably I won't be able to
moderate them until next weekend, then go on as usual.

Regards,
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr

http://www.gunduz.org

Re: [pgsql-www] News and Events moderation (again)

On Sat, 2008-07-05 at 20:16 +0100, Dave Page wrote:
> >
> > As I wrote you on IM 2 days before, I'm more than willing to re-take
> > this over.
>
> Thanks Devrim. I assume from my Inbox that you have access? :-p

Yeah. Actually I had time for these stuff already, but I thought people
were taking care of those, but apparently I was wrong.

Cleared up the comments (and news) queue.

Cheers,
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr

http://www.gunduz.org

Re: [pgsql-www] News and Events moderation (again)

On Sat, Jul 5, 2008 at 7:34 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
> On Sat, 2008-07-05 at 17:04 +0100, Dave Page wrote:
>> I assume you've been unable to do so,
>> therefore I'd like to ask Devrim to take over from you on Events and
>> Doc Comments moderation, assuming his previous offer stands?
>
> As I wrote you on IM 2 days before, I'm more than willing to re-take
> this over.

Thanks Devrim. I assume from my Inbox that you have access? :-p

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [PATCHES] pgbench minor fixes

On Sun, 2008-07-06 at 00:06 +1000, Russell Smith wrote:
> Simon Riggs wrote:
> > Minor patch on pgbench
> >
> > 1. -i option should run vacuum analyze only on pgbench tables, not *all*
> > tables in database.
> >
> How does this work with custom scripts?

I don't think we can justify vacuuming every table in the database just
so we get any tables being used for one set of tests. Not in a utility
that many users have access to, not just superusers. If you use a custom
script you just need to write a pre-test script and run it with psql.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] psql command setting

Simon Riggs <simon@2ndquadrant.com> writes:
> Recent patch allowed \timing [on|off]
> This patch allows same option on all remaining toggles, so every option
> works in the same way.

We already discussed that and rejected it, because the remaining toggles
aren't really toggles.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[pgeu-general] Call for Papers - European PGDay 2008

Following the phenomenal international success of PGDay 2007, the 2008
event, to be held on October 17th and 18th will include both an Italian
program and a European program running in parallel. This call for papers
is for the European program - expect a separate one for the Italian one.

The conference will once again be held in the beautiful historic
surroundings of the Monash University Prato Centre in Prato, a small
walled town near Florence, Tuscany.

European PGDay 2008 is the main European event about PostgreSQL this
year. If you're doing interesting PostgreSQL work in Europe or
elsewhere, this is your chance to tell people about it! Our goal is to
have a complete track of English talks during the conference, so that at
any given time there will be at least one English and one Italian talk
available to go to.

We are interested in talks about all things related to PostgreSQL, for
example:

* PostgreSQL development projects/efforts
* Solutions built on PostgreSQL
* Migration projects
* Advocacy efforts
* ... and much more ...

For more information, as well as instructions on how to submit a paper,
please visit the PGDay website at:
http://www.pgday.org/en/call4papers


--
Magnus Hagander
PostgreSQL Europe


--
Sent via pgeu-general mailing list (pgeu-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgeu-general

Re: [GENERAL] AT TIME ZONE and DST in UTC<->CET conversion

Gregory Stark <stark@enterprisedb.com> writes:
> ISTM this is the one that's wrong. "CET" is standard time, it, GMT+1.

> If you want a timezone which switches between CET and CST automatically you
> should use something like Europe/Paris.

Well, actually he *is* using such a zone:

regression=# select * from pg_timezone_names where name = 'CET';
name | abbrev | utc_offset | is_dst
------+--------+------------+--------
CET | CEST | 02:00:00 | t
(1 row)

But

regression=# select * from pg_timezone_abbrevs where abbrev = 'CET';
abbrev | utc_offset | is_dst
--------+------------+--------
CET | 01:00:00 | f
(1 row)

The problem is that one of these two statements is using the abbrev
meaning and the other is using the timezone meaning.

We don't have much control over the zone definition, so I'm thinking
maybe the abbrev should be removed from the tznames lists. But that
seems a bit sucky too. Does anyone have any idea if the zic folk would
be responsive to a complaint that defining a timezone with the same
name as an abbreviation is a bad idea?

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Target lists can have at most 1664 entries?

On Wed, Jul 02, 2008 at 09:22:50AM +0200, Bjørn T Johansen wrote:
> On Wed, 02 Jul 2008 03:04:04 -0400
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > =?UTF-8?Q?Bj=C3=B8rn?= T Johansen <btj@havleik.no> writes:
> > > What does this mean and how can it be fixed?
> >
> > Reduce the number of columns in your SELECTs?
> >
> > This whiffs to me of excruciatingly bad schema design. How could
> > you possibly need upwards of a thousand columns in a query result?
> > IMHO reasonable column counts are O(10), not O(bignum).
>
> Well, I do agree but it is not my design and a "fix" in PostgreSQL
> would be quicker than fixing the design....

That's where you're badly mistaken. Your application is completely
broken, and trying to adjust everybody else's Postgres to accommodate
*your* broken application is both selfish and short-sighted. It's
selfish because you're asking others to do work they don't need to do
just so you can avoid doing work you need to do, and it's
short-sighted because your application is guaranteed to be broken in
lots of other ways if it's broken this way.

Fix the application, and if you can't, find another job where they're
not being idiots. There are plenty of Postgres-related jobs out
there.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] PATCH: CITEXT 2.0

"David E. Wheeler" <david@kineticode.com> writes:
>>> Also OPERATOR || has probably wrong negator.
>>
>> Right, good catch.

> Stupid question: What would the negation of || actually be? There
> isn't one is, there?

Per the docs, NEGATOR is only sensible for operators returning boolean.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] [Postgresql 8.2.3] autovacuum starting up even after disabling ?

dushy <dushyanth@gmail.com> writes:
> On Fri, Jul 4, 2008 at 10:56 PM, Adrian Klaver <aklaver@comcast.net> wrote:
>> One question? Did you do pg_ctl reload after changing the config file?

> I did not change any config yet - autovacuum was always disabled since
> the day PG was set up.

A mistake here seems by far the most likely explanation. Does
"show autovacuum" confirm that it's off?

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [PATCHES] Explain XML patch v2

On Sat, Jul 5, 2008 at 10:41 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> It can be optional since plugins can add parameters also.

GUCs I assume you mean, not grammar. Unless I'm misreading the code
though, if the plugin is there it will always run instead of the
regular explain code, so presumabiy that's optional as in XML or
nothing, not XML or standard output.

> It wouldn't take long to make up a plugin for 8.3 once this patch has
> been committed to core for 8.4, so if you're saying you'd definitely
> like it in core then I'm OK with that.

If i's always there it's definitely more useful to pgAdmin, and
doesn't require that we instruct users to install more server side
plugin code to use the features they want.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] pgbench minor fixes

On Sun, 6 Jul 2008, Russell Smith wrote:

> Simon Riggs wrote:
>> Minor patch on pgbench
>>
>> 1. -i option should run vacuum analyze only on pgbench tables, not *all*
>> tables in database.
>>
> How does this work with custom scripts?

That's the initialization step. It creates the 4 tables, populates then,
then runs VACCUM ANALYZE. There is no notion of what script you'll end up
executing yet. If you have a truly custom script that works against other
data instead of the pgbench tables, you won't even be executing this
initialization bit.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [HACKERS] introduction of WIP window function patch

On Sat, Jul 05, 2008 at 07:04:29PM +0900, H.Harada wrote:
> Hi,
>
> As I proposed a month before, I am working on window function.

Very nice!

> http://umitanuki.net/pgsql/wfv01/design.html
>
> The problem is, as written in the "Things to discussed" section of the
> document, how you define window functions (e.g. RANK()). My idea is to
> treat them as specialized functions such as SET OF functions and mark
> it in pg_proc. But this doesn't resolve RANK() boundary problem.

Actually, I would make RANK() and ROW_NUMBER() act more like
aggregates. ISTM you have two kinds of window functions:

- aggregation: a result is calculated over a set and the result copied
across all the rows.
- order depenadant: same as above, but the result is different for each
row.

I think you could make the latter work using the current aggregation
setup, just by calling the final_func for each row rather than just
once at the end.

That would make RANK() a normal aggrgate which returns the number of
distinct values seen so far (assuming input is ordered) and
ROW_NUMBER() is just an alias for COUNT().

I hope this is clear, let me know if it doesn't make sense.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org>

http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Re: [PATCHES] pgbench minor fixes

Simon Riggs wrote:
> Minor patch on pgbench
>
> 1. -i option should run vacuum analyze only on pgbench tables, not *all*
> tables in database.
>
How does this work with custom scripts?
> 2. pre-run cleanup step was DELETE FROM HISTORY then VACUUM HISTORY.
> This is just a slow version of TRUNCATE HISTORY.
>
>


--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[PATCHES] pgbench minor fixes

Index: contrib/pgbench/pgbench.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/contrib/pgbench/pgbench.c,v
retrieving revision 1.80
diff -c -r1.80 pgbench.c
*** contrib/pgbench/pgbench.c 9 May 2008 15:53:07 -0000 1.80
--- contrib/pgbench/pgbench.c 5 Jul 2008 12:58:09 -0000
***************
*** 1080,1086 ****

/* vacuum */
fprintf(stderr, "vacuum...");
! executeStatement(con, "vacuum analyze");

fprintf(stderr, "done.\n");
PQfinish(con);
--- 1080,1089 ----

/* vacuum */
fprintf(stderr, "vacuum...");
! executeStatement(con, "vacuum analyze branches");
! executeStatement(con, "vacuum analyze tellers");
! executeStatement(con, "vacuum analyze accounts");
! executeStatement(con, "vacuum analyze history");

fprintf(stderr, "done.\n");
PQfinish(con);
***************
*** 1757,1764 ****
fprintf(stderr, "starting vacuum...");
executeStatement(con, "vacuum branches");
executeStatement(con, "vacuum tellers");
! executeStatement(con, "delete from history");
! executeStatement(con, "vacuum history");
fprintf(stderr, "end.\n");

if (do_vacuum_accounts)
--- 1760,1766 ----
fprintf(stderr, "starting vacuum...");
executeStatement(con, "vacuum branches");
executeStatement(con, "vacuum tellers");
! executeStatement(con, "truncate history");
fprintf(stderr, "end.\n");

if (do_vacuum_accounts)
Minor patch on pgbench

1. -i option should run vacuum analyze only on pgbench tables, not *all*
tables in database.

2. pre-run cleanup step was DELETE FROM HISTORY then VACUUM HISTORY.
This is just a slow version of TRUNCATE HISTORY.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support

[PATCHES] psql command setting

Index: src/bin/psql/command.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/bin/psql/command.c,v
retrieving revision 1.190
diff -c -r1.190 command.c
*** src/bin/psql/command.c 11 Jun 2008 10:48:17 -0000 1.190
--- src/bin/psql/command.c 5 Jul 2008 12:15:02 -0000
***************
*** 182,191 ****
*/
if (strcmp(cmd, "a") == 0)
{
! if (pset.popt.topt.format != PRINT_ALIGNED)
! success = do_pset("format", "aligned", &pset.popt, pset.quiet);
else
! success = do_pset("format", "unaligned", &pset.popt, pset.quiet);
}

/* \C -- override table title (formerly change HTML caption) */
--- 182,203 ----
*/
if (strcmp(cmd, "a") == 0)
{
! char *opt = psql_scan_slash_option(scan_state,
! OT_NORMAL, NULL, false);
! if (opt)
! {
! if (ParseVariableBool(opt))
! success = do_pset("format", "aligned", &pset.popt, pset.quiet);
! else
! success = do_pset("format", "unaligned", &pset.popt, pset.quiet);
! }
else
! {
! if (pset.popt.topt.format != PRINT_ALIGNED)
! success = do_pset("format", "aligned", &pset.popt, pset.quiet);
! else
! success = do_pset("format", "unaligned", &pset.popt, pset.quiet);
! }
}

/* \C -- override table title (formerly change HTML caption) */
***************
*** 538,547 ****
/* HTML mode */
else if (strcmp(cmd, "H") == 0 || strcmp(cmd, "html") == 0)
{
! if (pset.popt.topt.format != PRINT_HTML)
! success = do_pset("format", "html", &pset.popt, pset.quiet);
else
! success = do_pset("format", "aligned", &pset.popt, pset.quiet);
}


--- 550,571 ----
/* HTML mode */
else if (strcmp(cmd, "H") == 0 || strcmp(cmd, "html") == 0)
{
! char *opt = psql_scan_slash_option(scan_state,
! OT_NORMAL, NULL, false);
! if (opt)
! {
! if (ParseVariableBool(opt))
! success = do_pset("format", "html", &pset.popt, pset.quiet);
! else
! success = do_pset("format", "aligned", &pset.popt, pset.quiet);
! }
else
! {
! if (pset.popt.topt.format != PRINT_HTML)
! success = do_pset("format", "html", &pset.popt, pset.quiet);
! else
! success = do_pset("format", "aligned", &pset.popt, pset.quiet);
! }
}


Index: src/bin/psql/help.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/bin/psql/help.c,v
retrieving revision 1.129
diff -c -r1.129 help.c
*** src/bin/psql/help.c 11 Jun 2008 10:55:43 -0000 1.129
--- src/bin/psql/help.c 5 Jul 2008 12:30:39 -0000
***************
*** 220,237 ****
fprintf(output, "\n");

fprintf(output, _("Formatting\n"));
! fprintf(output, _(" \\a toggle between unaligned and aligned output mode\n"));
fprintf(output, _(" \\C [STRING] set table title, or unset if none\n"));
fprintf(output, _(" \\f [STRING] show or set field separator for unaligned query output\n"));
! fprintf(output, _(" \\H toggle HTML output mode (currently %s)\n"),
ON(pset.popt.topt.format == PRINT_HTML));
fprintf(output, _(" \\pset NAME [VALUE] set table output option\n"
" (NAME := {format|border|expanded|fieldsep|footer|null|\n"
" numericlocale|recordsep|tuples_only|title|tableattr|pager})\n"));
! fprintf(output, _(" \\t show only rows (currently %s)\n"),
ON(pset.popt.topt.tuples_only));
fprintf(output, _(" \\T [STRING] set HTML <table> tag attributes, or unset if none\n"));
! fprintf(output, _(" \\x toggle expanded output (currently %s)\n"),
ON(pset.popt.topt.expanded));
fprintf(output, "\n");

--- 220,237 ----
fprintf(output, "\n");

fprintf(output, _("Formatting\n"));
! fprintf(output, _(" \\a [on|off] toggle between unaligned and aligned output mode\n"));
fprintf(output, _(" \\C [STRING] set table title, or unset if none\n"));
fprintf(output, _(" \\f [STRING] show or set field separator for unaligned query output\n"));
! fprintf(output, _(" \\H [on|off] toggle or set HTML output mode (currently %s)\n"),
ON(pset.popt.topt.format == PRINT_HTML));
fprintf(output, _(" \\pset NAME [VALUE] set table output option\n"
" (NAME := {format|border|expanded|fieldsep|footer|null|\n"
" numericlocale|recordsep|tuples_only|title|tableattr|pager})\n"));
! fprintf(output, _(" \\t [on|off] toggle or set showing rows only (currently %s)\n"),
ON(pset.popt.topt.tuples_only));
fprintf(output, _(" \\T [STRING] set HTML <table> tag attributes, or unset if none\n"));
! fprintf(output, _(" \\x [on|off] toggle or set expanded output (currently %s)\n"),
ON(pset.popt.topt.expanded));
fprintf(output, "\n");

***************
*** 245,251 ****

fprintf(output, _("External\n"));
fprintf(output, _(" \\cd [DIR] change the current working directory\n"));
! fprintf(output, _(" \\timing [on|off] toggle timing of commands (currently %s)\n"),
ON(pset.timing));
fprintf(output, _(" \\! [COMMAND] execute command in shell or start interactive shell\n"));
fprintf(output, "\n");
--- 245,251 ----

fprintf(output, _("External\n"));
fprintf(output, _(" \\cd [DIR] change the current working directory\n"));
! fprintf(output, _(" \\timing [on|off] toggle or set timing of commands (currently %s)\n"),
ON(pset.timing));
fprintf(output, _(" \\! [COMMAND] execute command in shell or start interactive shell\n"));
fprintf(output, "\n");
Recent patch allowed \timing [on|off]

This patch allows same option on all remaining toggles, so every option
works in the same way. We now have the ability to do
\a [on|off]
\H [on|off]

Patch also corrects help, which didn't show that \x and \t could already
be directly set, even though help said they were toggles.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support

Re: [PERFORM] Subquery WHERE IN or WHERE EXISTS faster?

Hi Ulrich, do you try with

SELECT p.speed FROM processor p
INNER JOIN users_processors up ON p.id=up.processorid
AND up.userid=1
?
Or your question is only about IN and EXIST?

regards,

Sergio Gabriel Rodriguez
Corrientes - Argentina
http://www.3trex.com.ar

On Sat, Jun 28, 2008 at 7:07 PM, Ulrich <ulrich.mierendorff@gmx.net> wrote:
> Hi,
> I have added a bit of dummy Data, 100000 processors, 10000 users, each user
> got around 12 processors.
>
> I have tested both queries. First of all, I was surprised that it is that
> fast :) Here are the results:
>
>
> EXPLAIN ANALYZE SELECT speed FROM processors WHERE id IN (SELECT processorid
> FROM users_processors WHERE userid=4040) ORDER BY speed ASC LIMIT 10 OFFSET
> 1;
>
> Limit (cost=113.73..113.75 rows=7 width=5) (actual time=0.335..0.340
> rows=10 loops=1)
> -> Sort (cost=113.73..113.75 rows=8 width=5) (actual time=0.332..0.333
> rows=11 loops=1)
> Sort Key: processors.speed
> Sort Method: quicksort Memory: 17kB
> -> Nested Loop (cost=47.22..113.61 rows=8 width=5) (actual
> time=0.171..0.271 rows=13 loops=1)
> -> HashAggregate (cost=47.22..47.30 rows=8 width=4) (actual
> time=0.148..0.154 rows=13 loops=1)
> -> Bitmap Heap Scan on users_processors
> (cost=4.36..47.19 rows=12 width=4) (actual time=0.074..0.117 rows=13
> loops=1)
> Recheck Cond: (userid = 4040)
> -> Bitmap Index Scan on
> users_processors_userid_index (cost=0.00..4.35 rows=12 width=0) (actual
> time=0.056..0.056 rows=13 loops=1)
> Index Cond: (userid = 4040)
> -> Index Scan using processors_pkey on processors
> (cost=0.00..8.28 rows=1 width=9) (actual time=0.006..0.007 rows=1 loops=13)
> Index Cond: (processors.id =
> users_processors.processorid)
> Total runtime: 0.471 ms
> (13 rows)
>
> ___________
>
> EXPLAIN ANALYZE SELECT speed FROM processors WHERE EXISTS (SELECT 1 FROM
> users_processors WHERE userid=4040 AND processorid=processors.id) ORDER BY
> speed ASC LIMIT 10 OFFSET 1;
>
> Limit (cost=831413.86..831413.89 rows=10 width=5) (actual
> time=762.475..762.482 rows=10 loops=1)
> -> Sort (cost=831413.86..831538.86 rows=50000 width=5) (actual
> time=762.471..762.473 rows=11 loops=1)
> Sort Key: processors.speed
> Sort Method: quicksort Memory: 17kB
> -> Seq Scan on processors (cost=0.00..830299.00 rows=50000 width=5)
> (actual time=313.591..762.411 rows=13 loops=1)
> Filter: (subplan)
> SubPlan
> -> Index Scan using users_processors_pkey on
> users_processors (cost=0.00..8.29 rows=1 width=0) (actual time=0.006..0.006
> rows=0 loops=100000)
> Index Cond: ((userid = 4040) AND (processorid = $0))
> Total runtime: 762.579 ms
> (10 rows)
>
>
>
>
> As you can see the second query is much slower. First I thought "Just a
> difference of 0.3ms?", but then I realized that it was 762ms not 0.762 ;-).
> Both queries return the same result, so I will use #1 and count(*) takes
> just 0.478ms if I use query #1.
>
> Kind Regards,
> Ulrich
>
> Tom Lane wrote:
>>
>> Ulrich <ulrich.mierendorff@gmx.net> writes:
>>
>>>
>>> People say that [EXISTS is faster]
>>>
>>
>> People who say that are not reliable authorities, at least as far as
>> Postgres is concerned. But it is always a bad idea to extrapolate
>> results on toy tables to large tables --- quite aside from measurement
>> noise and caching issues, the planner might pick a different plan when
>> faced with large tables. Load up a realistic amount of data and then
>> see what you get.
>>
>> regards, tom lane
>>
>>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [GENERAL] AT TIME ZONE and DST in UTC<->CET conversion

Jaromír TalíÅ™ <jaromir.talir@nic.cz> writes:

> postgres# select '2008-06-01 10:10:10 UTC' AT TIME ZONE 'CET';
> timezone
> ---------------------
> 2008-06-01 12:10:10

ISTM this is the one that's wrong. "CET" is standard time, it, GMT+1.

If you want a timezone which switches between CET and CST automatically you
should use something like Europe/Paris.

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [PERFORM] Subquery WHERE IN or WHERE EXISTS faster?

Hi Ulrich, do you try with

SELECT p.speed FROM processor p
INNER JOIN users_processors up ON p.id=up.processorid
AND up.userid=1
?
Or your question is only about IN and EXIST?

regards,

Sergio Gabriel Rodriguez
Corrientes - Argentina
http://www.3trex.com.ar

On Mon, Jun 30, 2008 at 4:44 AM, Rusty Conover <rconover@infogears.com> wrote:
>
> On Jun 30, 2008, at 1:29 AM, Ulrich wrote:
>
>> I think it will be fast, because the "IN set", which is the result of
>> "SELECT processorid FROM users_processors WHERE userid=4040", is limited to
>> a maximum of ~500 processors which is not very big. Increasing Postgres' RAM
>> would be difficult for me, because I am only running a very small server
>> with 256MB RAM and the webserver also likes to use some RAM.
>>
>> Does Postgre cache the HASH-Table for later use? For example when the user
>> reloads the website.
>>
>
> No the hash table only lives as long as the query is being executed. If
> you're looking for generic caching, I'd suggest memcached may be able to
> fill your needs.
>
> Cheers,
>
> Rusty
> --
> Rusty Conover
> InfoGears Inc.
> http://www.infogears.com
>
>
>
>
>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

[PATCHES] Bug fix for pg_standby keepfiles calculation

Index: contrib/pg_standby/pg_standby.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/contrib/pg_standby/pg_standby.c,v
retrieving revision 1.12
diff -c -r1.12 pg_standby.c
*** contrib/pg_standby/pg_standby.c 17 May 2008 01:28:21 -0000 1.12
--- contrib/pg_standby/pg_standby.c 5 Jul 2008 11:44:29 -0000
***************
*** 323,329 ****
if (seg_diff > seg)
{
log_diff++;
! seg = MaxSegmentsPerLogFile - seg_diff;
}
else
seg -= seg_diff;
--- 323,329 ----
if (seg_diff > seg)
{
log_diff++;
! seg = MaxSegmentsPerLogFile - (seg_diff - seg);
}
else
seg -= seg_diff;
Fix minor bug in pg_standby, noted by Ferenc Felhoffer

Request immediate apply to CVS HEAD and 8.3

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support

[PERFORM] How much work_mem to configure...

How can I tell if my work_mem configuration is enough to support all  Postgres user activities on the server I am managing?

Where do I find the indication if the number is lower than needed.

Thanks,
Jessica

[ADMIN] performance cost for varchar(20), varchar(255), and text

I am tuning a database created by someone else.

I noticed that some column lengths were defined longer than needed.

For example, an Id column is holding a stand length of 20 characters but was defined as varchar(255).

On some other columns, for example, a Description column is supposed to hold less than 100 characters but defined as text.

I am trying to understand the performance impact if a column is over defined in the following cases:

1. char(20) vs varchar(20)

2. varchar(20) vs varchar(255)

3. varchar(255) vs text


thanks,
Jessica

Re: [pgadmin-hackers] Enabling SQL text field in the SQL tab of object dialog

Index: pgadmin/include/dlg/dlgProperty.h
===================================================================
--- pgadmin/include/dlg/dlgProperty.h (revision 7390)
+++ pgadmin/include/dlg/dlgProperty.h (working copy)
@@ -60,6 +60,8 @@
void EnableOK(bool enable);
virtual bool IsUpToDate() { return true; };
void ShowObject();
+
+ void FillSQLTextfield();

void CheckValid(bool &enable, const bool condition, const wxString &msg);
static dlgProperty *CreateDlg(frmMain *frame, pgObject *node, bool asNew, pgaFactory *factory=0);
@@ -86,6 +88,7 @@
void OnChange(wxCommandEvent &ev);
void OnChangeOwner(wxCommandEvent &ev);
void OnChangeStc(wxStyledTextEvent& event);
+ void OnChangeReadOnly(wxCommandEvent& event);

protected:
void AddUsers(ctlComboBoxFix *cb1, ctlComboBoxFix *cb2=0);
@@ -97,7 +100,7 @@
pgDatabase *database;

frmMain *mainForm;
- ctlSQLBox *sqlPane;
+ wxPanel *sqlPane;

wxTextValidator numericValidator;

@@ -105,6 +108,10 @@
wxTextCtrl *txtName, *txtOid, *txtComment;
ctlComboBox *cbOwner;
ctlComboBox *cbClusterSet;
+ wxCheckBox *chkReadOnly;
+ ctlSQLBox *sqlTextField1;
+ ctlSQLBox *sqlTextField2;
+ bool enableSQL2;

int width, height;
wxTreeItemId item, owneritem;
Index: pgadmin/dlg/dlgProperty.cpp
===================================================================
--- pgadmin/dlg/dlgProperty.cpp (revision 7390)
+++ pgadmin/dlg/dlgProperty.cpp (working copy)
@@ -59,8 +59,6 @@
#include "schema/pgUser.h"


-
-
class replClientData : public wxClientData
{
public:
@@ -72,6 +70,9 @@
};


+#define CTRLID_CHKSQLTEXTFIELD 1000
+
+
BEGIN_EVENT_TABLE(dlgProperty, DialogWithHelp)
EVT_NOTEBOOK_PAGE_CHANGED(XRCID("nbNotebook"), dlgProperty::OnPageSelect)

@@ -80,6 +81,8 @@
EVT_COMBOBOX(XRCID("cbOwner"), dlgProperty::OnChange)
EVT_TEXT(XRCID("txtComment"), dlgProperty::OnChange)

+ EVT_CHECKBOX(CTRLID_CHKSQLTEXTFIELD, dlgProperty::OnChangeReadOnly)
+
EVT_BUTTON(wxID_HELP, dlgProperty::OnHelp)
EVT_BUTTON(wxID_OK, dlgProperty::OnOK)
EVT_BUTTON(wxID_APPLY, dlgProperty::OnApply)
@@ -90,6 +93,8 @@
{
readOnly=false;
sqlPane=0;
+ sqlTextField1=0;
+ sqlTextField2=0;
processing=false;
mainForm=frame;
database=0;
@@ -117,6 +122,11 @@
txtComment = CTRL_TEXT("txtComment");
cbOwner = CTRL_COMBOBOX2("cbOwner");
cbClusterSet = CTRL_COMBOBOX2("cbClusterSet");
+
+ wxString db = wxT("Database");
+ wxString ts = wxT("Tablespace");
+ enableSQL2 = db.Cmp(factory->GetTypeName()) == 0
+ || ts.Cmp(factory->GetTypeName()) == 0;

wxNotebookPage *page=nbNotebook->GetPage(0);
wxASSERT(page != NULL);
@@ -311,8 +321,41 @@

void dlgProperty::CreateAdditionalPages()
{
- sqlPane = new ctlSQLBox(nbNotebook, CTL_PROPSQL, wxDefaultPosition, wxDefaultSize, wxTE_MULTILINE | wxSUNKEN_BORDER | wxTE_READONLY | wxTE_RICH2);
+ // create a panel
+ sqlPane = new wxPanel(nbNotebook);
+
+ // add panel to the notebook
nbNotebook->AddPage(sqlPane, wxT("SQL"));
+
+ // create a flex grid sizer
+ wxFlexGridSizer *fgsizer = new wxFlexGridSizer(1, 5, 5);
+
+ // add checkbox to the panel
+ chkReadOnly = new wxCheckBox(sqlPane, CTRLID_CHKSQLTEXTFIELD, wxT("Read only"));
+ chkReadOnly->SetValue(true);
+ fgsizer->Add(chkReadOnly, 1, wxALL | wxALIGN_LEFT, 5);
+
+ // add the first text entry box
+ sqlTextField1 = new ctlSQLBox(sqlPane, CTL_PROPSQL,
+ wxDefaultPosition, wxDefaultSize,
+ wxTE_MULTILINE | wxSUNKEN_BORDER | wxTE_RICH2);
+ fgsizer->Add(sqlTextField1, 1, wxALL | wxEXPAND, 5);
+
+ // add the second text entry box (if needed)
+ if (enableSQL2)
+ {
+ sqlTextField2 = new ctlSQLBox(sqlPane, CTL_PROPSQL,
+ wxDefaultPosition, wxDefaultSize,
+ wxTE_MULTILINE | wxSUNKEN_BORDER | wxTE_RICH2);
+ fgsizer->Add(sqlTextField2, 1, wxALL | wxEXPAND, 5);
+ }
+
+ fgsizer->AddGrowableCol(0);
+ fgsizer->AddGrowableRow(1);
+ fgsizer->AddGrowableRow(2);
+
+ sqlPane->SetAutoLayout(true);
+ sqlPane->SetSizer(fgsizer);
}


@@ -506,6 +549,85 @@
}


+void dlgProperty::OnChangeReadOnly(wxCommandEvent &ev)
+{
+ size_t pos;
+ bool showmessage;
+
+ showmessage = chkReadOnly->GetValue()
+ && ! (!enableSQL2 && GetSql().Length() == 0 && sqlTextField1->GetText().Cmp(_("-- nothing to change")) == 0)
+ && ! (!enableSQL2 && GetSql().Length() == 0 && sqlTextField1->GetText().Cmp(_("-- definition incomplete")) == 0)
+ && ! (enableSQL2 && GetSql().Length() == 0 && GetSql2().Length() == 0 && sqlTextField1->GetText().Cmp(_("-- nothing to change")) == 0 && sqlTextField2->GetText().Length() == 0)
+ && ! (enableSQL2 && GetSql().Length() == 0 && GetSql2().Length() == 0 && sqlTextField1->GetText().Cmp(_("-- definition incomplete")) == 0 && sqlTextField2->GetText().Length() == 0)
+ && (sqlTextField1->GetText().Cmp(GetSql()) != 0 || (enableSQL2 && sqlTextField2->GetText().Cmp(GetSql2()) != 0));
+
+ if (showmessage)
+ {
+ if (wxMessageBox(_("Are you sure you wish to cancel your edit?"), _("SQL editor"), wxYES_NO|wxNO_DEFAULT) == wxNO)
+ {
+ chkReadOnly->SetValue(false);
+ return;
+ }
+ }
+
+ sqlTextField1->SetReadOnly(chkReadOnly->GetValue());
+ if (enableSQL2)
+ {
+ sqlTextField2->SetReadOnly(chkReadOnly->GetValue());
+ }
+ for (pos = 0; pos < nbNotebook->GetPageCount() - 1; pos++)
+ {
+ nbNotebook->GetPage(pos)->Enable(chkReadOnly->GetValue());
+ }
+
+ if (chkReadOnly->GetValue())
+ {
+ FillSQLTextfield();
+ }
+}
+
+
+void dlgProperty::FillSQLTextfield()
+{
+ // create a function because this is a duplicated code
+ sqlTextField1->SetReadOnly(false);
+ if (enableSQL2)
+ {
+ sqlTextField2->SetReadOnly(false);
+ }
+ if (btnOK->IsEnabled())
+ {
+ wxString tmp;
+ if (cbClusterSet && cbClusterSet->GetSelection() > 0)
+ {
+ replClientData *data=(replClientData*)cbClusterSet->GetClientData(cbClusterSet->GetSelection());
+ tmp.Printf(_("-- Execute replicated using cluster \"%s\", set %ld\n"), data->cluster.c_str(), data->setId);
+ }
+ sqlTextField1->SetText(tmp + GetSql());
+ if (enableSQL2)
+ {
+ sqlTextField2->SetText(GetSql2());
+ }
+ }
+ else
+ {
+ if (GetObject())
+ sqlTextField1->SetText(_("-- nothing to change"));
+ else
+ sqlTextField1->SetText(_("-- definition incomplete"));
+ if (enableSQL2)
+ {
+ sqlTextField2->SetText(wxT(""));
+ }
+ }
+ sqlTextField1->SetReadOnly(true);
+ if (enableSQL2)
+ {
+ sqlTextField2->SetReadOnly(true);
+ }
+}
+
+
bool dlgProperty::tryUpdate(wxTreeItemId collectionItem)
{
ctlTree *browser=mainForm->GetBrowser();
@@ -608,7 +730,7 @@
mainForm->GetSqlPane()->SetReadOnly(true);
}
}
- else if (item)
+ else if (item && chkReadOnly->GetValue())
{
wxTreeItemId collectionItem=item;

@@ -753,8 +875,25 @@
return;
}

- wxString sql=GetSql();
- wxString sql2=GetSql2();
+ wxString sql;
+ wxString sql2;
+ if (chkReadOnly->GetValue())
+ {
+ sql = GetSql();
+ sql2 = GetSql2();
+ }
+ else
+ {
+ sql = sqlTextField1->GetText();
+ if (enableSQL2)
+ {
+ sql2 = sqlTextField2->GetText();
+ }
+ else
+ {
+ sql2 = wxT("");
+ }
+ }

if (!apply(sql, sql2))
{
@@ -768,27 +907,10 @@

void dlgProperty::OnPageSelect(wxNotebookEvent& event)
{
- if (sqlPane && event.GetSelection() == (int)nbNotebook->GetPageCount()-1)
+ if (sqlTextField1 && chkReadOnly->GetValue() &&
+ event.GetSelection() == (int)nbNotebook->GetPageCount()-1)
{
- sqlPane->SetReadOnly(false);
- if (btnOK->IsEnabled())
- {
- wxString tmp;
- if (cbClusterSet && cbClusterSet->GetSelection() > 0)
- {
- replClientData *data=(replClientData*)cbClusterSet->GetClientData(cbClusterSet->GetSelection());
- tmp.Printf(_("-- Execute replicated using cluster \"%s\", set %ld\n"), data->cluster.c_str(), data->setId);
- }
- sqlPane->SetText(tmp + GetSql() + GetSql2());
- }
- else
- {
- if (GetObject())
- sqlPane->SetText(_("-- nothing to change"));
- else
- sqlPane->SetText(_("-- definition incomplete"));
- }
- sqlPane->SetReadOnly(true);
+ FillSQLTextfield();
}
}

Dave Page a écrit :
> On Tue, Jul 1, 2008 at 11:52 AM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>
>> I'm at the PostgreSQL booth, for the RMLL in Mont-de-Marsan
>> (http://rmll.info). I'm trying the wifi system :)
>
> :-)
>
>> Here is the patch that fixes your issue on Win32. Works great on Win32 and
>> Linux... I'm not sure for Mac OS X though.
>
> Hmm, this still isn't looking so good I'm afraid:
>

:-/

> - If I open the properties dialogue on a database, click the SQL tab
> and then uncheck Read only, having changed nothing, I get asked if I
> want to cancel my edit. I believe this is because in the edit case,
> GetSQL() will return nothing, whilst the textbox may contain '--
> nothing to change'
>

Fixed.

> - The sizing is still wrong on Mac. Worse, the text boxes no longer
> resize on the resizeable dialogues (dlgFunction, dlgPackage,
> dlgTrigger and friends).
>
> I would suggest avoiding trying to calculate the dimensions in code -

I like this idea.

> in my experience this almost never works well. Instead, I would
> suggest laying the two textboxes and the checkbox in a sizer and
> letting that do the work. Not only should that be easier to code (once
> you fully understand sizers!), but it should work properly on all
> platforms, and be resize-friendly.
>

OK, it wasn't easy to do. But it now works. I don't specify any size and
the rendering looks great... on Linux. On Windows, it doesn't. I spent
part of the last two days to try to understand the Windows behaviour but
I failed. Do you have any idea on the Windows behavior? is there
something Windows specific when we use the flex grid sizer?

> The same should probably be done for other standard tabs (eg,
> privileges, gucs) when you update all the XRC files as you discussed
> previously.
>
> Sorry, I know this isn't what you wanted to hear - but we'll get there :-)
>

Oh no problem with me on this. I'm just worried on the number of bad
patches.

The patch attached fixed some issues:
* The "Are you sure..." message is displayed only when "Read Only" is
checked.
* No button is the default on the "Are you sure" message (which has a
weird behaviour... hitting Esc will validate the dialog and the user
will lose his changes... I'm not sure we should keep this).
* the first issue you had.
* Sizing problems fixed on Linux with a wxFlexGridSizer.

Remaining issues:
* Objects' size on Windows (and Max OS X ?).


--
Guillaume.

http://www.postgresqlfr.org

http://dalibo.com

[GENERAL] AT TIME ZONE and DST in UTC<->CET conversion

First, if I do conversion from UTC to CET and back when a timestamp is
OUTSIDE of daylight saving period, it's correct:

postgres# select '2008-01-01 10:10:10 UTC' AT TIME ZONE 'CET';
timezone
---------------------
2008-01-01 11:10:10

postgres# select '2008-01-01 11:10:10 CET' AT TIME ZONE 'UTC';
timezone
---------------------
2008-01-01 10:10:10


When I do the same INSIDE this period just the UCT->CET direction is
correct but back direction will fail subtracting only 1 hour instead of
2 hours.

postgres# select '2008-06-01 10:10:10 UTC' AT TIME ZONE 'CET';
timezone
---------------------
2008-06-01 12:10:10

postgres# select '2008-06-01 12:10:10 CET' AT TIME ZONE 'UTC';
timezone
---------------------
2008-06-01 11:10:10

If it supports automatic discovery of DST in conversion from UTC to CET
(and this is great), why it doesn't support this discovery in opposit
direction?

Regards,
Jaromir

[HACKERS] introduction of WIP window function patch

Hi,

As I proposed a month before, I am working on window function.
Although this work is at quite early step, I would like to introduce
it since a part of it have been finished. If you can afford and are
interested in it, please review the document and patch, or compile the
applied source to execute an attached sample SQL.

http://umitanuki.net/pgsql/wfv01/design.html

Currently, only aggregation over window does work. I am planning to
work for the combination of window and normal aggregation from now on,
which I guess I can manage to do.

The problem is, as written in the "Things to discussed" section of the
document, how you define window functions (e.g. RANK()). My idea is to
treat them as specialized functions such as SET OF functions and mark
it in pg_proc. But this doesn't resolve RANK() boundary problem.

I am so happy with any kind of comments, reviews or critiques.

Regards,

--
Hitoshi Harada

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH: CITEXT 2.0

"David E. Wheeler" <david@kineticode.com> writes:

> do I need to worry about memory leaks in citext_eq, citext_ne, citext_gt,
> etc.,

yes

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Ask me about EnterpriseDB's 24x7 Postgres support!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH: CITEXT 2.0

"David E. Wheeler" <david@kineticode.com> writes:

> On Jul 3, 2008, at 09:53, Alvaro Herrera wrote:
>
>>> Thanks. What would citext_hash() look like? I don't see a text_hash() to
>>> borrow from anywhere in src/.
>>
>> See hash_any(). I assume the difficulty is making sure that
>> hash("FOO") = hash("foo") ...
>
> Great, big help, thank you. So does this look sensible?
>
> txt = cilower( PG_GETARG_TEXT_PP(0) );
> str = VARDATA_ANY(txt);
>
> result = hash_any((unsigned char *) str, VARSIZE_ANY_EXHDR(txt));

I thought your data type implemented a locale dependent collation, not just
a case insensitive collation. That is, does this hash agree with your
citext_eq on strings like "foo bar" <=> "foobar" and "fooß" <=> "fooss" ?

You may have to use strxfrm

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Ask me about EnterpriseDB's PostGIS support!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [PATCHES] Explain XML patch v2

On Fri, 2008-07-04 at 17:20 +0100, Simon Riggs wrote:
> <!ELEMENT plan (estimate, runtime?)>

Sorry, I noticed a few typos in my sample DTD.

<!ELEMENT plan (node+)> with some additional elements for stats

and the attlist below was for the <node> not <plan> element

<!ATTLIST node
nodetype CDATA #REQUIRED>


--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Explain XML patch v2

On Fri, 2008-07-04 at 19:38 +0100, Dave Page wrote:
> On Fri, Jul 4, 2008 at 5:20 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >
> > * If the patch was implemented as an ExplainOneQuery_hook we would be
> > able to use this with 8.3 also, which might be interesting. So there's
> > no real need for this to be a patch on core.
>
> Would that mean that instead of being an optional format that pgAdmin
> could request with appropriate grammar, it would be something that was
> only available if the plugin was loaded, and would replace regular
> EXPLAIN output? If so, that would be extremely inconvenient, and next
> to useless for general purpose utilities.

It can be optional since plugins can add parameters also.

It wouldn't take long to make up a plugin for 8.3 once this patch has
been committed to core for 8.4, so if you're saying you'd definitely
like it in core then I'm OK with that.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [COMMITTERS] pgsql: Fix a couple of bugs in win32 shmem name generation: * Don't cut

Alvaro Herrera wrote:
> Magnus Hagander wrote:
>> Tom Lane wrote:
>
>>> According to what you just told me, the original coding is storing the
>>> name in a "local namespace", which presumably means it won't conflict
>>> anyway. Ergo, the existing coding is simply broken and there's nothing
>>> we can do about it.
>> Local namespace = Session local, not process local. So it would properly
>> protect against two processes started in the same session. One session
>> is, for example, an interactive login. But not if they were started by
>> different users, since they'd be in different sessions.
>
> But those different users would not have access to the same set of
> files, so it wouldn't work anyway, right?

Depends on what permissions you set on the directory, obviously....
Default ones depend on windows version and where in the filesystem they go.

//Magnus

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP

hello david,

i did some quick testing with this wonderful patch.
it seems there are some flaws in there still:

test=# explain select count(*)
test-#         from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL SELECT DISTINCT n+1 FROM t )
test(#                 SELECT * FROM t WHERE n < 5000000000) as t
test-#         WHERE n < 100;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!> \q

this one will kill the planner :(
removing the (totally stupid) distinct avoids the core dump.


i found one more issue;

-- broken: wrong result
test=# select count(*) from ( WITH RECURSIVE t(n) AS (
        SELECT 1 UNION ALL SELECT n + 1 FROM t)
        SELECT * FROM t WHERE n < 5000000000) as t WHERE n < (
                select count(*) from ( WITH RECURSIVE t(n) AS (
                        SELECT 1 UNION ALL SELECT n + 1 FROM t )
        SELECT * FROM t WHERE n < 5000000000) as t WHERE n < 100) ;
 count
-------
     1
(1 row)

if i am not totally wrong, this should give us a different result.

i am looking forward to see this patch in core :).
it is simply wonderful ...

many thanks,

hans






On Jul 3, 2008, at 1:11 AM, David Fetter wrote:

Folks,

Please find patch enclosed, including some documentation.

Can we see about getting this in this commitfest?

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate<recursive_query-7.patch.bz2>
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:



--
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, 2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql-support.de, www.postgresql-support.com