Re: [pgus-board] Flyer text, v.1

Tri fold! getting dinner in the oven, then i'll plug it in and send a PDF

-selena

On Sat, Jul 19, 2008 at 5:25 PM, Michael Alan Brewer <mbrewer@gmail.com> wrote:
> Hey, y'all; here's my first pass at putting together the PgUS flyer:
>
> [Is this a single sheet? Trifold?]
> ###############################
> The United States PostgreSQL Association welcomes you!
>
> ***GOALS***
> The US PostgreSQL Association (PgUS) is a non profit corporation with
> the following primary goals:
>
> (a) Educate, promote and support the creation, development and use of
> the PostgreSQL Open Source Database software, a software system which
> is available to the general public without charge;
>
> (b) Provide information and education regarding the use of PostgreSQL; and
>
> (c) Organize, hold and conduct meetings, discussion, and forums on the
> contemporary issues concerning the use of PostgreSQL.
>
> What do these mean for you?
>
>>>>.COM
> * Create sponsorship programs that utilize the power and influence of
> the for-profit market to continue the promotion of PostgreSQL by
> educating professional users and corporations on the benefits of using
> the database. Further the education of PostgreSQL through the use of development
> grants.
>
>>>>.EDU
> * Promote the use of PostgreSQL in academic curriculum, educational
> support applications, and in papers and presentations. From the server
> to the classroom, expand the presence of PostgreSQL.
>
>>>>.YOU
> * Support and offer PostgreSQL Conferences, Workshops and other
> educational events centered around PostgreSQL, such as the PostgreSQL Community
> conferences (EAST and WEST). Support User Groups in their quest to
> bring community together as a
> way to advance their own knowledge of PostgreSQL.
>
> ***MEMBERSHIP***
> There are many benefits to PgUS membership:
>
> 1. A postgresql.us email forward (username@postgresql.us)
> 2. Aggregation of member blog
> 3. Eligibility for grants
> 4. Eligibility to serve or lead committee
> 5. Ability to vote in elections
> 6. Ability to bring motions
> 7. Professional listing in member directory
> 8. A postgresql.us Jabber(R) account
>
> Membership dues shall be the following:
>
> $75 -- Professional
> $20 -- Student
>
> **********************
>
> To learn more about us and our mission, please visit us on the web at:
>
> postgresql.us
>
> #####################################################
> #####################################################
> This is 286 words (according to, umm, Word). The parts in ****CAPS
> **** and/or in >>>CAPS would require special formatting (larger font,
> drop letter, etc.); Selena, would this fit in your template?
>
> Please send suggestions/corrections/updates ASAP; I'd like to get
> this to the printer. ;)
>
> ---Michael Brewer
> mbrewer@gmail.com
>
> --
> Sent via pgus-board mailing list (pgus-board@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgus-board
>

--
Selena Deckelmann
United States PostgreSQL Association - http://www.postgresql.us
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily

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

Re: [pgsql-www] How to contribute to site?

Francisco Reyes wrote:
> I am looking at https://pgweb.postgresql.org and don't see any pointers
> on how one contributes to the pg doc project.
>
> Also checked http://wiki.postgresql.org/wiki/Developer_FAQ and the wiki
> in general.
>
> Any URLs or any pointers on how to contribute?
> I particular I want to provide examples for this page:
> http://www.postgresql.org/docs/8.3/interactive/ddl-partitioning.html

Well, that's a different codebase from pgweb. pgweb deals with the
website itself; the docs are produced from SGML source found in the core
Postgres source. You can probably check out git.postgresql.org to get
this source, edit it (see the doc/src/sgml directory), and use GIT to
build a patch and mail it to the pgsql-docs list.

(You could also use CVS if you feel so inclined, but it probably does
not have any benefit over GIT).

Note that pgsql-www is not involved anywhere in this task :-)

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

[pgus-board] Flyer text, v.1

Hey, y'all; here's my first pass at putting together the PgUS flyer:

[Is this a single sheet? Trifold?]
###############################
The United States PostgreSQL Association welcomes you!

***GOALS***
The US PostgreSQL Association (PgUS) is a non profit corporation with
the following primary goals:

(a) Educate, promote and support the creation, development and use of
the PostgreSQL Open Source Database software, a software system which
is available to the general public without charge;

(b) Provide information and education regarding the use of PostgreSQL; and

(c) Organize, hold and conduct meetings, discussion, and forums on the
contemporary issues concerning the use of PostgreSQL.

What do these mean for you?

>>>.COM
* Create sponsorship programs that utilize the power and influence of
the for-profit market to continue the promotion of PostgreSQL by
educating professional users and corporations on the benefits of using
the database. Further the education of PostgreSQL through the use of development
grants.

>>>.EDU
* Promote the use of PostgreSQL in academic curriculum, educational
support applications, and in papers and presentations. From the server
to the classroom, expand the presence of PostgreSQL.

>>>.YOU
* Support and offer PostgreSQL Conferences, Workshops and other
educational events centered around PostgreSQL, such as the PostgreSQL Community
conferences (EAST and WEST). Support User Groups in their quest to
bring community together as a
way to advance their own knowledge of PostgreSQL.

***MEMBERSHIP***
There are many benefits to PgUS membership:

1. A postgresql.us email forward (username@postgresql.us)
2. Aggregation of member blog
3. Eligibility for grants
4. Eligibility to serve or lead committee
5. Ability to vote in elections
6. Ability to bring motions
7. Professional listing in member directory
8. A postgresql.us Jabber(R) account

Membership dues shall be the following:

$75 -- Professional
$20 -- Student

**********************

To learn more about us and our mission, please visit us on the web at:

postgresql.us

#####################################################
#####################################################
This is 286 words (according to, umm, Word). The parts in ****CAPS
**** and/or in >>>CAPS would require special formatting (larger font,
drop letter, etc.); Selena, would this fit in your template?

Please send suggestions/corrections/updates ASAP; I'd like to get
this to the printer. ;)

---Michael Brewer
mbrewer@gmail.com

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

Re: [HACKERS] Postgres-R: primary key patches

Markus Wanner wrote:

> (Although, I'm still less than thrilled about the internal storage
> format of these tuple collections. That can certainly be improved and
> simplified.)

Care to expand more on what it is? On Replicator we're using the binary
send/recv routines to transmit tuples. (Obviously this fails when the
master and slave have differing binary output, but currently we just
punt on this point).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
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] Reducing memory usage of insert into select operations? [Solved]

Francisco Reyes wrote:

> I knew it sounded too good to be true.
> 1- The trigger was not set in the master (ie nothing went to the children).
> 2- The master had no index and no RI.. so it was a straight insert.
>
> I corrected (ie set the trigger in the master and RI in the children).
> Has been running for 10 hours and has not finished.

FWIW it tends to be faster to do the bulk load first and add the
indexes and constraints later. (Though obviously you must be prepared
to cope with the failing rows, if any). However, if you do this
INSERT/SELECT thing frequently, this is probably not very workable.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
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] Getting to universal binaries for Darwin

Am Saturday, 19. July 2008 schrieb Tom Lane:
> The bad news is that if you only do that, only the arch that you
> actually build on will work.  We have configure set up to insert
> various hardware-dependent definitions into pg_config.h and
> ecpg_config.h, and if you don't have the right values visible for
> each compilation, the resulting executables will fail.

I'd imagine a related problem are the run tests in configure. They will
produce results for the platform that you run configure on. More properly,
you should run configure in cross-compilation mode (twice, and then merge the
output, as previously described), but I am not sure how that will turn out
when configure attempts to determine alignment and endianness with
compilation-only tests. You should probably check some of those results very
carefully and help it out with some cache variables.

--
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] Reducing memory usage of insert into select operations? [Solved]

Alvaro Herrera writes:

> Heh -- but are the FKs now checked? Try inserting something that
> violates the constraints and see if they are rejected.

I knew it sounded too good to be true.
1- The trigger was not set in the master (ie nothing went to the children).
2- The master had no index and no RI.. so it was a straight insert.

I corrected (ie set the trigger in the master and RI in the children). Has
been running for 10 hours and has not finished.

The good news is that memory doesn't seem to be going up.
I will give it till tomorrow AM.. and if hasn't finished will turn off the
foreign keys in the children. Already modified the scripts so I can easily
build/drop the foreign keys as needed.

--
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] .psqlrc output for \pset commands

Am Thursday, 17. July 2008 schrieb Bruce Momjian:

> > Anyways the thing that struck me as odd was the messages appearing
> > *before* the header. It seems to me the header should print followed by
> > .psqlrc output followed by normal output.
>
> Do you like this better?
>
> $ psql test
> psql (8.4devel)
> Type "help" for help.
> Output format is wrapped.
>
> test=>
>
> The attached patch accomplishes this.

The psqlrc file must be read before the welcome message is printed, so that
you can disable the welcome message in the psqlrc file. Otherwise we are
reopening the whole issue of when and whether to print a welcome message that
we had just settled.

--
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] Getting to universal binaries for Darwin

Tom Lane wrote:
> You can get around that by hacking up the generated config files
> with #ifdef __i386__ and so on to expose the correct values of
> the hardware-dependent symbols to each build. Of course you have
> to know what the correct values are --- if you don't have a sample
> of each architecture handy to run configure against, it'd be easy
> to miss some things. And even then it's pretty tedious. I am
> not sure if it is possible or worth the trouble to try to automate
> this part better.

Hm - configure *does* the right thing if CFLAGS is set to *just* "-arch
i386" or "-arch ppc" (at least on intel hardware, because OSX can run
ppc binaries there, but not vice versa), right? If this is true, we need
some way to run configure multiple times, once for each arch, but then
still get *one* set of Makefiles that have all the archs in their CFLAGS..

> Modulo the above problems, I was able to build i386+ppc binaries that
> do in fact work on both architectures. I haven't got any 64-bit Apple
> machines to play with, so there might be 64-bit issues I missed.
> Still, this is a huge step forward compared to what was discussed here:
> http://archives.postgresql.org/pgsql-general/2008-02/msg00200.php
I think that my MacBook should be able to build and run 64-bit binaries,
so I can test that if you want. Do you have a script that does the
necessary config file magic, or did you do that by hand?

regards, Florian Pflug

--
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] pugs.postgresql.org error in pg_query()

On Fri, Jul 18, 2008 at 4:44 AM, Alexey Klyukin <alexk@commandprompt.com> wrote:

> I've noticed that pugs.postgresql.org shows this error on some pages:

Thank you. I had applied that patch a while back, but Marc tried to
upgrade using ports, and it failed. Must have eaten the patch
somewhere along the line.

I've re-applied the patch!

-selena

--
Selena Deckelmann
United States PostgreSQL Association - http://www.postgresql.us
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily

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

Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error

Glyn Astill <glynastill@yahoo.co.uk> writes:
> Would the mips specific code behave differently on different oses?

I'm more worried about there being more than one type of MIPS CPU out
there. Do all qubes contain exactly the same sub-architecture?
The references to "mips2" in s_lock.h are attention-getting ...

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] Getting to universal binaries for Darwin

Adriaan van Os <postgres@microbizz.nl> writes:
> Tom Lane wrote:
>> You can get around that by hacking up the generated config files
>> with #ifdef __i386__ and so on to expose the correct values of
>> the hardware-dependent symbols to each build. Of course you have
>> to know what the correct values are --- if you don't have a sample
>> of each architecture handy to run configure against, it'd be easy
>> to miss some things. And even then it's pretty tedious. I am
>> not sure if it is possible or worth the trouble to try to automate
>> this part better.

> It may be less pain to simply config and build for ppc and i386 in separate build directories and
> then glue the resulting binaries together with lipo

That might give you working executables, but you still need a
glued-together pg_config.h for installation purposes, if you'd
like people to be able to build extensions against the installation.

In any case, the preceding thread showed exactly how to do it that
way, and it didn't look like "less pain" to me ...

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] Postgres-R: primary key patches

Hi,

chris wrote:
> You may want to have a chat with Jan; he's got some thoughts on a more
> general purpose mechanism that would be good for this as well as for
> (we think) extremely efficient bulk data loading.

Jan, mind to share your thoughts? What use cases for such a general
purpose mechanism do you see?

What I can imagine doing on top of Postgres-R is: splitting up the data
and feeding multiple backends with it. Unlike Postgres-R's internal use,
you'd still have to check the data against constraints, I think.

It would involve the origin backend asking for help from the manager.
That one checks for available helper backends and then serves as a
message dispatcher between the origin and helper backends (as it does
for replication purposes). Please note that it already uses shared
memory extensively, so the manager doesn't need to copy around the data
itself.

Regards

Markus

--
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] Postgres-R: primary key patches

Hi,

chris wrote:
> I agree with you that tables are *supposed* to have primary keys;
> that's proper design, and if tables are missing them, then something
> is definitely broken.

Ah, I see, so you are not concerned about tables with a PRIMARY KEY for
which one wants another REPLICATION KEY, but only about tables without a
PRIMARY KEY, for which one doesn't want a PRIMARY KEY in the first place.

However, that's a general limitation of replication at tuple level: you
need to be able to uniquely identify tuples. (Unlike replication on
storage level, which can use the storage location for that).

> Sometimes, unfortunately, people make errors in design, and we wind up
> needing to accomodate situations that are "less than perfect."
>
> The "happy happenstance" is that, in modern versions of PostgreSQL, a
> unique index may be added in the background so that this may be
> rectified without outage if you can live with a "candidate primary
> key" rather than a true PRIMARY KEY.

I cannot see any reason for not wanting a PRIMARY KEY, but wanting
replication, and therefore a REPLICATION KEY.

Or are you saying we should add a hidden REPLICATION KEY for people who
are afraid of schema changes and dislike a visible primary key? Would
you want to hide the underlying index as well?

> It seems to me that this extension can cover over a number of "design
> sins," which looks like a very kind accomodation where it is surely
> preferable to design it in earlier rather than later.

Sorry, but I fail to see any real advantage of that covering of "sins".
I would find it rather confusing to have keys and indices hidden from
the admin. It's not like an additional index or a primary key would lead
to functional changes.

That's certainly different for additional columns, where a SELECT *
could all of a sudden return more columns than before. So that's the
exception where I agree that hiding such an additional column like we
already do for system columns would make sense. That's for example the
situation where you add an 'id' column later on and make that the new
primary (and thus replication) key. Maybe that's what you meant?
However, even in that case, I wouldn't hide the index nor the primary
key, but only the column.

Regards

Markus

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

Re: [ADMIN] Database Link

On 2008-07-19, at 10:00, Govind wrote:

> Hi all,
>
> Like oracle dblink, is it possible to connect two database's in
> greenplum??? If yes please pass the command how to create the dblink
> to connect two databases.
>
> Regards
>
> Govindarajan
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin

http://www.postgresql.org/docs/8.3/static/contrib.html

and

http://www.postgresql.org/docs/8.3/static/contrib-dblink.html

all dblink functions
http://www.postgresql.org/docs/8.3/static/dblink.html

-
Pawel Socha
pawel.socha@gmail.com

perl -le 's**02).4^&-%2,).^9%4^!./4(%2^3,!#+7!2%^53%2&**y%& -;^[%"`-
{ a%%s%%$_%ee'

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

Re: [pgadmin-hackers] Dialogs review

Index: pgadmin/ui/dlgCast.xrc
===================================================================
--- pgadmin/ui/dlgCast.xrc (revision 7393)
+++ pgadmin/ui/dlgCast.xrc (working copy)
@@ -2,147 +2,221 @@
<resource>
<object class="wxDialog" name="dlgCast">
<title></title>
- <object class="wxNotebook" name="nbNotebook">
- <object class="notebookpage">
- <label>Properties</label>
- <object class="wxPanel" name="pnlProperties">
- <object class="wxStaticText" name="stName">
-
- <label>Name</label>
-
- <pos>5,7d</pos>
+ <style>wxDEFAULT_DIALOG_STYLE|wxCAPTION|wxSYSTEM_MENU|wxRESIZE_BORDER|wxRESIZE_BOX|wxTHICK_FRAME</style>
+ <object class="wxFlexGridSizer">
+ <cols>1</cols>
+ <object class="sizeritem">
+ <object class="wxNotebook" name="nbNotebook">
+ <object class="notebookpage">
+ <label>Properties</label>
+ <object class="wxPanel" name="pnlProperties">
+ <object class="wxFlexGridSizer">
+ <cols>2</cols>
+ <rows>8</rows>
+ <vgap>5</vgap>
+ <hgap>5</hgap>
+ <growablerows>6</growablerows>
+ <growablecols>1</growablecols>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stName">
+ <label>Name</label>
+ <pos>5,7d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="wxTextCtrl" name="txtCastname">
+ <pos>70,5d</pos>
+ <size>135,-1d</size>
+ </object>
+ <flag>wxEXPAND|wxALIGN_TOP|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stOID">
+ <label>OID</label>
+ <pos>5,22d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="wxTextCtrl" name="txtOID">
+ <pos>70,20d</pos>
+ <size>135,-1d</size>
+ </object>
+ <flag>wxEXPAND|wxALIGN_TOP|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stSourceType">
+ <label>Source type</label>
+ <pos>5,37d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="ctlComboBox" name="cbSourceType">
+ <content/>
+ <pos>70,35d</pos>
+ <size>130,12d</size>
+ <style>wxCB_DROPDOWN</style>
+ </object>
+ <flag>wxEXPAND|wxALIGN_TOP|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stTargetType">
+ <label>Target type</label>
+ <pos>5,52d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="ctlComboBox" name="cbTargetType">
+ <content/>
+ <pos>70,50d</pos>
+ <size>130,12d</size>
+ <style>wxCB_DROPDOWN</style>
+ </object>
+ <flag>wxEXPAND|wxALIGN_TOP|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stFunction">
+ <label>Function</label>
+ <pos>5,67d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="wxComboBox" name="cbFunction">
+ <content/>
+ <pos>70,65d</pos>
+ <size>135,12d</size>
+ <style>wxCB_READONLY|wxCB_DROPDOWN</style>
+ </object>
+ <flag>wxEXPAND|wxALIGN_TOP|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stImplicit">
+ <label>Implicit</label>
+ <pos>5,82d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="wxCheckBox" name="chkImplicit">
+ <label></label>
+ <pos>70,80d</pos>
+ <size>13,12d</size>
+ </object>
+ <flag>wxEXPAND|wxALIGN_TOP|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stComment">
+ <label>Comment</label>
+ <pos>5,97d</pos>
+ </object>
+ <flag>wxALIGN_TOP|wxTOP|wxLEFT|wxRIGHT</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="wxTextCtrl" name="txtComment">
+ <pos>70,95d</pos>
+ <size>135,83d</size>
+ <style>wxTE_MULTILINE</style>
+ </object>
+ <flag>wxEXPAND|wxALL</flag>
+ <border>8</border>
+ </object>
+ <object class="sizeritem">
+ <object class="wxStaticText" name="stClusterSet">
+ <label>Use replication</label>
+ <pos>5,183d</pos>
+ </object>
+ <flag>wxALIGN_CENTRE_VERTICAL</flag>
+ </object>
+ <object class="sizeritem">
+ <object class="wxComboBox" name="cbClusterSet">
+ <content/>
+ <pos>70,181d</pos>
+ <size>135,12d</size>
+ <style>wxCB_READONLY|wxCB_DROPDOWN</style>
+ </object>
+ <flag>wxEXPAND|wxALIGN_TOP|wxALL</flag>
+ <border>8</border>
+ </object>
+ </object>
+ <selected>1</selected>
</object>
- <object class="wxTextCtrl" name="txtCastname">
-
- <pos>70,5d</pos>
-
- <size>135,-1d</size>
+ <pos>2,2d</pos>
+ <size>214,415d</size>
+ </object>
+ </object>
+ <flag>wxALL|wxGROW|wxALIGN_CENTRE</flag>
+ <border>3</border>
+ </object>
+ <growablecols>0</growablecols>
+ <growablerows>0</growablerows>
+ <object class="spacer">
+ <size>2,2d</size>
+ </object>
+ <object class="sizeritem">
+ <object class="wxFlexGridSizer">
+ <cols>7</cols>
+ <object class="spacer">
+ <size>3,3d</size>
</object>
- <object class="wxStaticText" name="stOID">
-
- <label>OID</label>
-
- <pos>5,22d</pos>
+ <object class="sizeritem">
+ <object class="wxButton" name="wxID_HELP">
+ <label>Help</label>
+ <pos>135,220d</pos>
+ </object>
</object>
- <object class="wxTextCtrl" name="txtOID">
-
- <pos>70,20d</pos>
-
- <size>135,-1d</size>
+ <object class="spacer">
+ <size>3,3d</size>
</object>
- <object class="wxStaticText" name="stSourceType">
-
- <label>Source type</label>
-
- <pos>5,37d</pos>
+ <object class="sizeritem">
+ <object class="wxButton" name="wxID_OK">
+ <label>&amp;OK</label>
+ <default>1</default>
+ <pos>135,220d</pos>
+ </object>
</object>
- <object class="ctlComboBox" name="cbSourceType">
-
- <content/>
-
- <pos>70,35d</pos>
-
- <size>135,12d</size>
-
- <style>wxCB_DROPDOWN</style>
+ <object class="spacer">
+ <size>3,3d</size>
</object>
- <object class="wxStaticText" name="stTargetType">
-
- <label>Target type</label>
-
- <pos>5,52d</pos>
+ <object class="sizeritem">
+ <object class="wxButton" name="wxID_CANCEL">
+ <label>&amp;Cancel</label>
+ <pos>176,220d</pos>
+ </object>
</object>
- <object class="ctlComboBox" name="cbTargetType">
-
- <content/>
-
- <pos>70,50d</pos>
-
- <size>135,12d</size>
-
- <style>wxCB_DROPDOWN</style>
+ <object class="spacer">
+ <size>3,3d</size>
</object>
- <object class="wxStaticText" name="stFunction">
-
- <label>Function</label>
-
- <pos>5,67d</pos>
- </object>
- <object class="wxComboBox" name="cbFunction">
-
- <content/>
-
- <pos>70,65d</pos>
-
- <size>135,12d</size>
-
- <style>wxCB_READONLY|wxCB_DROPDOWN</style>
- </object>
- <object class="wxStaticText" name="stImplicit">
-
- <label>Implicit</label>
-
- <pos>5,82d</pos>
- </object>
- <object class="wxCheckBox" name="chkImplicit">
-
- <label></label>
-
- <pos>70,80d</pos>
-
- <size>13,12d</size>
- </object>
- <object class="wxStaticText" name="stComment">
-
- <label>Comment</label>
-
- <pos>5,97d</pos>
- </object>
- <object class="wxTextCtrl" name="txtComment">
-
- <pos>70,95d</pos>
-
- <size>135,83d</size>
-
- <style>wxTE_MULTILINE</style>
- </object>
- <object class="wxStaticText" name="stClusterSet">
- <label>Use replication</label>
- <pos>5,183d</pos>
- </object>
- <object class="wxComboBox" name="cbClusterSet">
- <content/>
- <pos>70,181d</pos>
- <size>135,12d</size>
- <style>wxCB_READONLY|wxCB_DROPDOWN</style>
- </object>
+ <growablecols>2</growablecols>
</object>
-
- <selected>1</selected>
+ <flag>wxTOP|wxLEFT|wxRIGHT|wxGROW</flag>
</object>
- <pos>2,2d</pos>
- <size>214,215d</size>
+ <object class="spacer">
+ <size>3,3d</size>
+ </object>
+ <object class="sizeritem">
+ <object class="unknown" name="unkStatusBar">
+ <size>-1,15d</size>
+ </object>
+ <flag>wxGROW|wxALIGN_CENTRE</flag>
+ <border>3</border>
+ </object>
</object>
- <object class="wxButton" name="wxID_HELP">
-
- <label>Help</label>
-
- <pos>2,220d</pos>
- </object>
- <object class="wxButton" name="wxID_OK">
-
- <label>&amp;OK</label>
-
- <default>1</default>
-
- <pos>113,220d</pos>
- </object>
- <object class="wxButton" name="wxID_CANCEL">
-
- <label>&amp;Cancel</label>
-
- <pos>166,220d</pos>
- </object>
- <size>218,238d</size>
</object>
</resource>
Guillaume Lelarge a écrit :
> Dave Page a écrit :
>> On Mon, Jul 14, 2008 at 8:17 PM, Guillaume Lelarge
>> <guillaume@lelarge.info> wrote:
>>
>>> Hmmmm, I see... that I can't do anything till I get my Mac. I will
>>> work on
>>> it but I don't know now how to fix it.
>>
>> Understood. I'm really busy right now (yeah, I know I'm starting to
>> sound like a broken record with that one!) but if you send over the
>> latest version of the patch sometime I'll try out a couple of ideas
>> for this and the combo box thing when I can get five minutes..
>>
>
> :)
>
> Now that I have a MacMini, that I'm able to build a pgAdmin3.app file,
> things should go faster and with less burden. Or so I hope.
>
> BTW, I have the same issue with the two dialogs. I'm statring to work on
> this.
>

Okay... the wxListCtrl resize problem seems to be a wxMac confirmed bug.
See http://trac.wxwidgets.org/ticket/4814 bug report for more details.
Not sure about what we should do with this... debug the stuff on wxMac
source files? or simply put it in the BUGS file and continue the work ?

... hmmm ... (a few moments later) ... I can try to see what's going on
between 2.8.6 and 2.8.7 and if 2.8.6 works for us. (again a few moments
later) Nope, doesn't work on 2.8.6 and 2.8.0. I added a comment on the
trac tricket.

Anyways, I attach the new dlgCast.xrc patch file.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Re: [pgsql-fr-generale] Probleme Traffic réseau PostgreSQL

Antony Resbeut wrote:

> Lorsque je fais un "select toto from table where titi='x'" alors le
nombre
> d'octet de la réponse est identique entre Oracle et PostgreSQL
(parfois
> meilleur sous PostgreSQL).
>
> Si j'enlève la condition "where" alors PostgreSQL est beaucoup plus
bavard
> qu'Oracle aussi bien en nombre de packet que sur la taille des
packets. Et
> c'est pire si l'on fais un vidage "select * from table" brutal.
> Est-ce normal ?

La différence de taille peut s'expliquer par le fait que les nombres et
les
dates transitent par défaut en ASCII avec Postgres et probablement en
binaire
avec Oracle.
Réduire le trafic réseau avec Postgres doit être possible en passant
par des
curseurs binaires au lieu d'un select simple. Encore qu'au final ça
dépendra du
contenu effectif des données. puisque par exemple les petits nombres
prennent
moins de place en ASCII et les grands moins de place en binaire.

--
Daniel
PostgreSQL-powered mail user agent and storage:
http://www.manitou-mail.org

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

Re: [PERFORM] Performance on Sun Fire X4150 x64 (dd, bonnie++, pgbench)

pgbench is unrelated to the workload you are concerned with if ETL/ELT and decision support / data warehousing queries are your target.

Also - placing the xlog on dedicated disks is mostly irrelevant to data warehouse / decision support work or ELT.  If you need to maximize loading speed while concurrent queries are running, it may be necessary, but I think you'll be limited in load speed by CPU related to data formatting anyway.

The primary performance driver for ELT / DW is sequential transfer rate, thus the dd test at 2X memory.  With six data disks of this type, you should expect a maximum of around 6 x 80 = 480 MB/s.  With RAID10, depending on the raid adapter, you may need to have two or more IO streams to use all platters, otherwise your max speed for one query would be 1/2 that, or 240 MB/s.

I'd suggest RAID5, or even better, configure all eight disks as a JBOD in the RAID adapter and run ZFS RAIDZ.  You would then expect to get about 7 x 80 = 560 MB/s on your single query.

That said, your single cpu on one query will only be able to scan that data at about 300 MB/s (try running a SELECT COUNT(*) against a table that is 2X memory size).

- Luke

----- Original Message -----
From: pgsql-performance-owner@postgresql.org <pgsql-performance-owner@postgresql.org>
To: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Sent: Sat Jul 19 09:19:43 2008
Subject: [PERFORM] Performance on Sun Fire X4150 x64 (dd, bonnie++, pgbench)


I'm trying to run a few basic tests to see what a current machine can
deliver (typical workload ETL like, long running aggregate queries,
medium size db ~100 to 200GB).

I'm currently checking the system (dd, bonnie++) to see if performances
are within the normal range but I'm having trouble relating it to
anything known. Scouting the archives there are more than a few people
familiar with it, so if someone can have a look at those numbers and
raise a flag where some numbers look very out of range for such system,
that would be appreciated. I also added some raw pgbench numbers at the end.

(Many thanks to Greg Smith, his pages was extremely helpful to get
started. Any mistake is mine)

Hardware:

Sun Fire X4150 x64

2 Quad-Core Intel(R) Xeon(R) X5460 processor (2x6MB L2, 3.16 GHz, 1333
MHz FSB)
16GB of memory (4x2GB PC2-5300 667 MHz ECC fully buffered DDR2 DIMMs)

6x 146GB 10K RPM SAS  in RAID10 - for os + data
2x 146GB 10K RPM SAS  in RAID1 - for xlog
Sun StorageTek SAS HBA Internal (Adaptec AAC-RAID)


OS is Ubuntu 7.10 x86_64 running  2.6.22-14
os in on ext3
data is on xfs noatime
xlog is on ext2 noatime


data
$ time sh -c "dd if=/dev/zero of=bigfile bs=8k count=4000000 && sync"
4000000+0 records in
4000000+0 records out
32768000000 bytes (33 GB) copied, 152.359 seconds, 215 MB/s

real    2m36.895s
user    0m0.570s
sys     0m36.520s

$ time dd if=bigfile of=/dev/null bs=8k
4000000+0 records in
4000000+0 records out
32768000000 bytes (33 GB) copied, 114.723 seconds, 286 MB/s

real    1m54.725s
user    0m0.450s
sys     0m22.060s


xlog
$ time sh -c "dd if=/dev/zero of=bigfile bs=8k count=4000000 && sync"
4000000+0 records in
4000000+0 records out
32768000000 bytes (33 GB) copied, 389.216 seconds, 84.2 MB/s

real    6m50.155s
user    0m0.420s
sys     0m26.490s

$ time dd if=bigfile of=/dev/null bs=8k
4000000+0 records in
4000000+0 records out
32768000000 bytes (33 GB) copied, 294.556 seconds, 111 MB/s

real    4m54.558s
user    0m0.430s
sys     0m23.480s



bonnie++ -s 32g -n 256

data:
Version  1.03       ------Sequential Output------ --Sequential Input-
--Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
/sec %CP
lid-statsdb-1   32G 101188  98 202523  20 107642  13 88931  88 271576 
19 980.7   2
                    ------Sequential Create------ --------Random
Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read---
-Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
/sec %CP
                256 11429  93 +++++ +++ 17492  71 11097  91 +++++ +++ 
2473  11



xlog
Version  1.03       ------Sequential Output------ --Sequential Input-
--Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
/sec %CP
lid-statsdb-1   32G 62973  59 69981   5 35433   4 87977  85 119749   9
496.2   1
                    ------Sequential Create------ --------Random
Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read---
-Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
/sec %CP
                256   551  99 +++++ +++ 300935  99   573  99 +++++ +++ 
1384  99

pgbench

postgresql 8.2.9 with data and xlog as mentioned above

postgresql.conf:
shared_buffers = 4GB
checkpoint_segments = 8
effective_cache_size = 8GB

Script running over scaling factor 1 to 1000 and running 3 times pgbench
with "pgbench -t 2000 -c 8 -S pgbench"

It's a bit limited and will try to do a much much longer run and
increase the # of tests and calculate mean and stddev as I have a pretty
large variation for the 3 runs sometimes (typically for the scaling
factor at 1000, the runs are respectively 1952, 940, 3162)  so the graph
is pretty ugly.

I get (scaling factor, size of db in MB, middle tps)

1 20 22150
5 82 22998
10 160 22301
20 316 22857
30 472 23012
40 629 17434
50 785 22179
100 1565 20193
200 3127 23788
300 4688 15494
400 6249 23513
500 7810 18868
600 9372 22146
700 11000 14555
800 12000 10742
900 14000 13696
1000 15000 940

cheers,

-- stephane

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

Re: [pgsql-fr-generale] Re: Réf. : [pgsql-fr-generale] Probleme Traffic réseau PostgreSQL

Jonathan Ballet a écrit :
> Bonjour,
>
> Le Sat, 19 Jul 2008 10:27:10 +0200, Guillaume Lelarge <guillaume@lelarge.info> a écrit :
>
>>> WireShark est vraiment génial, puisqu'il sait formater en clair les
>>> messages du protocole PostgreSQL :-)
>> Tout comme le fait Etherreal à ma connaissance. Mais j'avoue encore une
>> fois n'avoir jamais eu la curiosité de regarder ce que cela donnait.
>
> C'est normal, WireShark est le nouveau nom d'Ethereal :)
> (cf. http://www.wireshark.org/faq.html#q1.2 )
>

Oups... je ne suis pas trop l'actualité de ce soft. Quoi, ça s'est vu ? :)

Merci pour l'info.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

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

Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error

> From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>

> Tom Lane wrote:
> > Glyn Astill writes:
> >> No. Will recompile with debug info and post back when done.
> >
> > FWIW, the most likely issue here is the MIPS-specific assembly code in
> > src/include/storage/s_lock.h --- I'm not sure how many MIPS platforms
> > that's really been exercised on, but it may not work on yours. While
> > you're waiting for the rebuild you might try to find a MIPS guru to
> > show that code to.
>
> hmm well - lionfish (which is now offline due to a broken power supply)
> is actually a cobalt cube too (and is running debian). So if we really
> managed to break mipsel it must have happened in the last few months:
>
>
> http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=lionfish&br=HEAD
>
>
> Stefandumb here

Hmm, well I've still not ruled out the possibility that I've done something stupid yet. Also I see that lionfish is running sarge, and I'm running etch.

Once I get time to recompile I'll try and find out a little more.

Would the mips specific code behave differently on different oses? My other qube is running netbsd4, I'd be interested to see what goes off on that, however I'ts my live email/web/everything server and I didn't want to upset it.

__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

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

Re: [ADMIN] Query

On Sat, Jul 19, 2008 at 04:29:00PM +0530, Kartik wrote:
> hello there,i am new to postgresql
> i am using postgresql 8.3.3 and i am writing one whole transaction. i want
> to know how to set auto commit off
> because if any error occours i want the whole transaction to be rolled back.
> when i tried alter database dbname set autocommit = off
> then it gives me error saying autocommit not available
> so can anyone suggest how to set autocommit as off so that i can rollback
> the transaction..

Simply issue the command "BEGIN" at the start of your transaction.
Then nothing will be commited until you issue "COMMIT" and you may abort
the transaction by sending "ROLLBACK" (or "ABORT").

HTH,

Tino.

--
"What we nourish flourishes." - "Was wir nähren erblüht."

www.craniosacralzentrum.de
www.forteego.de

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

[PERFORM] Performance on Sun Fire X4150 x64 (dd, bonnie++, pgbench)

I'm trying to run a few basic tests to see what a current machine can
deliver (typical workload ETL like, long running aggregate queries,
medium size db ~100 to 200GB).

I'm currently checking the system (dd, bonnie++) to see if performances
are within the normal range but I'm having trouble relating it to
anything known. Scouting the archives there are more than a few people
familiar with it, so if someone can have a look at those numbers and
raise a flag where some numbers look very out of range for such system,
that would be appreciated. I also added some raw pgbench numbers at the end.

(Many thanks to Greg Smith, his pages was extremely helpful to get
started. Any mistake is mine)

Hardware:

Sun Fire X4150 x64

2 Quad-Core Intel(R) Xeon(R) X5460 processor (2x6MB L2, 3.16 GHz, 1333
MHz FSB)
16GB of memory (4x2GB PC2-5300 667 MHz ECC fully buffered DDR2 DIMMs)

6x 146GB 10K RPM SAS in RAID10 - for os + data
2x 146GB 10K RPM SAS in RAID1 - for xlog
Sun StorageTek SAS HBA Internal (Adaptec AAC-RAID)

OS is Ubuntu 7.10 x86_64 running 2.6.22-14
os in on ext3
data is on xfs noatime
xlog is on ext2 noatime

data
$ time sh -c "dd if=/dev/zero of=bigfile bs=8k count=4000000 && sync"
4000000+0 records in
4000000+0 records out
32768000000 bytes (33 GB) copied, 152.359 seconds, 215 MB/s

real 2m36.895s
user 0m0.570s
sys 0m36.520s

$ time dd if=bigfile of=/dev/null bs=8k
4000000+0 records in
4000000+0 records out
32768000000 bytes (33 GB) copied, 114.723 seconds, 286 MB/s

real 1m54.725s
user 0m0.450s
sys 0m22.060s

xlog
$ time sh -c "dd if=/dev/zero of=bigfile bs=8k count=4000000 && sync"
4000000+0 records in
4000000+0 records out
32768000000 bytes (33 GB) copied, 389.216 seconds, 84.2 MB/s

real 6m50.155s
user 0m0.420s
sys 0m26.490s

$ time dd if=bigfile of=/dev/null bs=8k
4000000+0 records in
4000000+0 records out
32768000000 bytes (33 GB) copied, 294.556 seconds, 111 MB/s

real 4m54.558s
user 0m0.430s
sys 0m23.480s

bonnie++ -s 32g -n 256

data:
Version 1.03 ------Sequential Output------ --Sequential Input-
--Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
lid-statsdb-1 32G 101188 98 202523 20 107642 13 88931 88 271576
19 980.7 2
------Sequential Create------ --------Random
Create--------
-Create-- --Read--- -Delete-- -Create-- --Read---
-Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
/sec %CP
256 11429 93 +++++ +++ 17492 71 11097 91 +++++ +++
2473 11

xlog
Version 1.03 ------Sequential Output------ --Sequential Input-
--Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
lid-statsdb-1 32G 62973 59 69981 5 35433 4 87977 85 119749 9
496.2 1
------Sequential Create------ --------Random
Create--------
-Create-- --Read--- -Delete-- -Create-- --Read---
-Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
/sec %CP
256 551 99 +++++ +++ 300935 99 573 99 +++++ +++
1384 99

pgbench

postgresql 8.2.9 with data and xlog as mentioned above

postgresql.conf:
shared_buffers = 4GB
checkpoint_segments = 8
effective_cache_size = 8GB

Script running over scaling factor 1 to 1000 and running 3 times pgbench
with "pgbench -t 2000 -c 8 -S pgbench"

It's a bit limited and will try to do a much much longer run and
increase the # of tests and calculate mean and stddev as I have a pretty
large variation for the 3 runs sometimes (typically for the scaling
factor at 1000, the runs are respectively 1952, 940, 3162) so the graph
is pretty ugly.

I get (scaling factor, size of db in MB, middle tps)

1 20 22150
5 82 22998
10 160 22301
20 316 22857
30 472 23012
40 629 17434
50 785 22179
100 1565 20193
200 3127 23788
300 4688 15494
400 6249 23513
500 7810 18868
600 9372 22146
700 11000 14555
800 12000 10742
900 14000 13696
1000 15000 940

cheers,

-- stephane

--
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] Reducing memory usage of insert into select operations? [Solved]

Martijn van Oosterhout wrote:
> Can you make them not deferred?
How?

I found the issue.
I had the foreign key in the master table instead of the children.
Deleted RI from master table and put into the inherited partitions.
My whole 230 million rows merged in about an hour!
And I even had two of those running at the same time. (one setup with 14
partitions per month and another with 5 partitions per month to test
difference in performance).

It was so fast I even had to do a count(*) to make sure both actually
merged.
That is 117K rows per second for rows that were about 33 bytes long.
That only comes down to about 3 MB/sec+overhead, but still 117K rows/sec
is not too shabby.

In case it is of interest to anyone..
2 AMD dual core, 2GHz CPUs
12GB of RAM
shared_buffers 3GB
work_mem 64MB
256 check_point segments
10 min checkpoing_timeout
LSI controller with 128MB cache with BBU. Write cache enabled.

Many thanks to all that offered suggestions in the troubleshooting.

--
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] gsoc, oprrest function for text search

Jan Urbański wrote:
> The idea is (quoting a comment)
> /*
> * Traverse the tsquery preorder, calculating selectivity as:

Ekhm.
This should of course read "postorder"...

--
Jan Urbanski
GPG key ID: E583D7D2

ouden estin

--
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] Getting to universal binaries for Darwin

Tom Lane wrote:
> The bad news is that if you only do that, only the arch that you
> actually build on will work. We have configure set up to insert
> various hardware-dependent definitions into pg_config.h and
> ecpg_config.h, and if you don't have the right values visible for
> each compilation, the resulting executables will fail.
>
> You can get around that by hacking up the generated config files
> with #ifdef __i386__ and so on to expose the correct values of
> the hardware-dependent symbols to each build. Of course you have
> to know what the correct values are --- if you don't have a sample
> of each architecture handy to run configure against, it'd be easy
> to miss some things. And even then it's pretty tedious. I am
> not sure if it is possible or worth the trouble to try to automate
> this part better.

It may be less pain to simply config and build for ppc and i386 in separate build directories and
then glue the resulting binaries together with lipo
<http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/lipo.1.html> to make them
"universal".

Regards,

Adriaan van Os

--
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] Reducing memory usage of insert into select operations?

On Fri, Jul 18, 2008 at 04:48:26PM -0400, Francisco Reyes wrote:
> On 3:55 pm 07/18/08 Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > AfterTriggerEvents: 10553909248 total in 1268 blocks; 20432 free (6
> > > chunks); 10553888816 used
> >
> > Well, that's definitely your problem ...
>
> What is the overhead for each AfterTriggerEvent?

Can you make them not deferred? Then you don't need the memory either.

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.

[HACKERS] gsoc, oprrest function for text search

Here's a WIP patch implementing an oprrest function for tsvector @@
tsquery and tsquery @@ tsvector.

The idea is (quoting a comment)
/*
* Traverse the tsquery preorder, calculating selectivity as:
*
* selec(left_oper) * selec(right_oper) in AND nodes,
*
* selec(left_oper) + selec(right_oper) -
* selec(left_oper) * selec(right_oper) in OR nodes,
*
* 1 - select(oper) in NOT nodes
*
* freq[val] in VAL nodes, if the value is in MCELEM
* min(freq[MCELEM]) / 2 in VAL nodes, if it is not
*
*
* Implementation-wise, we sort the MCELEM array to use binary
* search on it.
*/

The patch still has many rough edges, but it applies to HEAD and passes
tests. I'm posting it mostly to get feedback about whether I'm going in
the right direction.

Cheers,
Jan

--
Jan Urbanski
GPG key ID: E583D7D2

ouden estin

[ADMIN] Query

hello there,

i am new to postgresql

i am using postgresql 8.3.3 and i am writing one whole transaction. i want to know how to set auto commit off

because if any error occours i want the whole transaction to be rolled back.

when i tried alter database dbname set autocommit = off

then it gives me error saying autocommit not available

so can anyone suggest how to set autocommit as off so that i can rollback the transaction..

thank you

waiting for your reply

regards 

kartik

Re: [pgsql-fr-generale] Re: Réf. : [pgsql-fr-generale] Probleme Traffic réseau PostgreSQL

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkiBsiUACgkQ+cFYTXJHUVBtNQCgiHHRAMWfEVSxZB+HlT5CJIaU
ZkoAmwZxwNLa+WQVkaH6Lc/zpiLOwGaH
=Sk6T
-----END PGP SIGNATURE-----
Bonjour,

Le Sat, 19 Jul 2008 10:27:10 +0200, Guillaume Lelarge <guillaume@lelarge.info> a écrit :

> > WireShark est vraiment génial, puisqu'il sait formater en clair les
> > messages du protocole PostgreSQL :-)
>
> Tout comme le fait Etherreal à ma connaissance. Mais j'avoue encore une
> fois n'avoir jamais eu la curiosité de regarder ce que cela donnait.

C'est normal, WireShark est le nouveau nom d'Ethereal :)
(cf. http://www.wireshark.org/faq.html#q1.2 )

Mes 2 centimes,

Jonathan

Re: [GENERAL] Backup/Restore of single table in multi TB database

On Fri, 2008-07-18 at 20:25 -0400, Francisco Reyes wrote:

> Does pg_snapclone works mostly on large rows or will it also be faster
> than pg_dump for narrow tables?

It allows you to run your dump in multiple pieces. Thats got nothing to
do with narrow or wide.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

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

Re: [ADMIN] unrecognized data type on dblink

I use 8.03.02.00 version driver.

> On Fri, Jul 18, 2008 at 9:24 AM, Aynur SANCAKLI
> <aynur.sancakli@kamusm.gov.tr> wrote:
>> Hi all,
>> I have a problem with dblink from oracle to postgresql.
>>
>> I cannot read varchar colums from postgresql db, in the trace file the
>> message is in the trace file is : unrecognized data type.
>
> Which Postgres ODBC driver are you using with heterogeneous services?
>
> --
> Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
> EnterpriseDB Corporation | fax: 732.331.1301
> 499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
> Edison, NJ 08837 | http://www.enterprisedb.com/
>

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

Re: [pgadmin-hackers] Dialogs review

Dave Page a écrit :
> On Mon, Jul 14, 2008 at 8:17 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>
>> Hmmmm, I see... that I can't do anything till I get my Mac. I will work on
>> it but I don't know now how to fix it.
>
> Understood. I'm really busy right now (yeah, I know I'm starting to
> sound like a broken record with that one!) but if you send over the
> latest version of the patch sometime I'll try out a couple of ideas
> for this and the combo box thing when I can get five minutes..
>

:)

Now that I have a MacMini, that I'm able to build a pgAdmin3.app file,
things should go faster and with less burden. Or so I hope.

BTW, I have the same issue with the two dialogs. I'm statring to work on
this.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

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

[pgsql-fr-generale] Re: Réf. : [pgsql-fr-generale] Probleme Traffic réseau PostgreSQL

Bonjour,

philippe.beaudoin@bull.net a écrit :
> [...]
> Comme il n'y avait pas beaucoup de réponse à ton post, j'ai pris mon
> courage à 2 mains et ai fait quelques analyses.

Le manque de réponses me semble dû au fait que personne ne s'est jamais
posé une telle question. Je pense bien que ça a déjà dû traverser
l'esprit de quelqu'un. Mais je ne me rappelle pas avoir lu une
quelconque étude ou mail à ce sujet ici et sur les listes anglophones.

> Pour ne pas avoir à me
> perdre dans les sources de PostgreSQL, j'ai installé WireShark sur mon
> micro et j'ai regardé les messages échangés entre pgAdmin sur mon micro et
> un PostgreSQL sur un serveur Linux.
> WireShark est vraiment génial, puisqu'il sait formater en clair les
> messages du protocole PostgreSQL :-)

Tout comme le fait Etherreal à ma connaissance. Mais j'avoue encore une
fois n'avoir jamais eu la curiosité de regarder ce que cela donnait.

> J'en ai déduit ceci sur la taille des messages échangés (hors couches
> réseau au dessous) :
>
> 1) A l'aller, on a le texte de la requête avec simplement un overhead de 6
> octets.
>
> 2) Au retour, on a un message (découpé éventuellement en plusieurs paquets
> selon la taille) composé de :
> - la description des lignes de la table résultat, dont la longueur en
> octets est égale à :
> 7 + ( 19 * nombre de colonnes) + somme des longueurs des noms des
> colonnes,
> - les lignes de données (voir plus bas),
> - 2 commandes "command completion" et "ready for query" représentant 18
> octets.
> Chaque ligne se compose de :
> - une partie fixe de 7 octets,
> - la liste des colonnes.
> Chaque colonne se compose de :
> - une partie fixe de 4 octets,
> - la valeur de la colonne.
>
> Tout est donc très logique.
>

Oui, en effet.

> 3) Contenu des colonnes :
> Pour les colonnes de type CHAR, on trouve le contenu de la colonne (je n'ai
> pas fait attention aux questions d'encodage qui peuvent j'imagine avoir un
> impact sur la taille physique de chaque caractère). il n'y a pas de
> compression, même pour les blancs à droite.

Exact pour l'encodage, la taille de chaque caractère en dépend. Quant à
la compression, je sais que PostgreSQL stocke parfois en compressant les
données. Pour ce qui est de l'envoi sur le réseau, je n'en sais rien du
tout.

> Pour les colonnes de type VARCHAR, on trouve évidemment la longueur réelle
> du contenu de la colonne et non sa longueur maximale.

Sa longueur maximale se trouve déjà dans la description des colonnes
envoyée au message précédent, non ?

> Pour les colonnes BYTEA, les octets "non imprimables" sont représentés par
> leur séquence d'escape (\nnn).
> Pour les colonnes numériques, la donnée est représentée sous forme de texte
> de longueur variable, c'est à dire la suite des chiffres nécessaires à la
> représentation du nombre.
>

Je suppose que, quand vous parlez de colonnes numériques, vous entendez
le type NUMERIC ? et pas les types int4, float, etc. ? si vous ne parlez
que du types NUMERIC, ça ne m'étonne pas, c'est déjà pas stocké comme un
entier/flottant.

> 4) Les requêtes retournant une ligne et celles retournant plusieurs lignes
> semblent avoir la même structure, quelle que soit le nombre de colonnes.
>
> Voici donc ma compréhension de la structure des messages. Elle est
> peut-être approximative mais ça peut aider. Quelqu'un a peut-être des
> précisions ?
>

En dehors de ce que je viens déjà de dire, non :)

> J'imagine que le dialogue entre pgAdmin et PostgreSQL que j'ai observé est
> le même que celui des autres clients et drivers disponibles. Quelqu'un
> peut-il me confirmer ?
>

Oui dans le sens où pgAdmin s'appuie sur la libpq (la bibliothèque C
d'accès au serveur PostgreSQL), donc tout outil basé sur la libpq fera
de même.

> Pour comprendre pourquoi Oracle qui est un peu moins bon sur 1 ligne
> devient meilleur sur plusieurs lignes, il faudrait faire ce même exercice
> avec Oracle.
> A moins que quelqu'un ait une déjà une idée sur la question...
>

Nope, ma connaissance d'Oracle est pratiquement nulle.

Merci pour ces infos. Même si ce n'est pas particulièrement nouveau,
c'est très intéressant à lire.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

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

Re: [PATCHES] Is autovacuum doing a wraparound-avoiding VACUUM?

Index: src/backend/postmaster/autovacuum.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/postmaster/autovacuum.c,v
retrieving revision 1.81
diff -c -r1.81 autovacuum.c
*** src/backend/postmaster/autovacuum.c 17 Jul 2008 21:02:31 -0000 1.81
--- src/backend/postmaster/autovacuum.c 19 Jul 2008 07:58:33 -0000
***************
*** 2657,2664 ****
/* Report the command and possible options */
if (tab->at_dovacuum)
snprintf(activity, MAX_AUTOVAC_ACTIV_LEN,
! "autovacuum: VACUUM%s",
! tab->at_doanalyze ? " ANALYZE" : "");
else
snprintf(activity, MAX_AUTOVAC_ACTIV_LEN,
"autovacuum: ANALYZE");
--- 2657,2665 ----
/* Report the command and possible options */
if (tab->at_dovacuum)
snprintf(activity, MAX_AUTOVAC_ACTIV_LEN,
! "autovacuum: VACUUM%s%s",
! tab->at_doanalyze ? " ANALYZE" : "",
! tab->at_wraparound ? " (to prevent wraparound)" : "");
else
snprintf(activity, MAX_AUTOVAC_ACTIV_LEN,
"autovacuum: ANALYZE");
Index: src/backend/postmaster/autovacuum.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/postmaster/autovacuum.c,v
retrieving revision 1.71.2.4
diff -c -r1.71.2.4 autovacuum.c
*** src/backend/postmaster/autovacuum.c 17 Jul 2008 21:02:41 -0000 1.71.2.4
--- src/backend/postmaster/autovacuum.c 19 Jul 2008 07:58:43 -0000
***************
*** 291,297 ****
static PgStat_StatTabEntry *get_pgstat_tabentry_relid(Oid relid, bool isshared,
PgStat_StatDBEntry *shared,
PgStat_StatDBEntry *dbentry);
! static void autovac_report_activity(VacuumStmt *vacstmt, Oid relid);
static void avl_sighup_handler(SIGNAL_ARGS);
static void avl_sigusr1_handler(SIGNAL_ARGS);
static void avl_sigterm_handler(SIGNAL_ARGS);
--- 291,297 ----
static PgStat_StatTabEntry *get_pgstat_tabentry_relid(Oid relid, bool isshared,
PgStat_StatDBEntry *shared,
PgStat_StatDBEntry *dbentry);
! static void autovac_report_activity(VacuumStmt *vacstmt, Oid relid, bool for_wraparound);
static void avl_sighup_handler(SIGNAL_ARGS);
static void avl_sigusr1_handler(SIGNAL_ARGS);
static void avl_sigterm_handler(SIGNAL_ARGS);
***************
*** 2633,2639 ****
MemoryContextSwitchTo(old_cxt);

/* Let pgstat know what we're doing */
! autovac_report_activity(&vacstmt, relid);

vacuum(&vacstmt, relids, bstrategy, for_wraparound, true);
}
--- 2633,2639 ----
MemoryContextSwitchTo(old_cxt);

/* Let pgstat know what we're doing */
! autovac_report_activity(&vacstmt, relid, for_wraparound);

vacuum(&vacstmt, relids, bstrategy, for_wraparound, true);
}
***************
*** 2650,2656 ****
* bother to report "<IDLE>" or some such.
*/
static void
! autovac_report_activity(VacuumStmt *vacstmt, Oid relid)
{
char *relname = get_rel_name(relid);
char *nspname = get_namespace_name(get_rel_namespace(relid));
--- 2650,2656 ----
* bother to report "<IDLE>" or some such.
*/
static void
! autovac_report_activity(VacuumStmt *vacstmt, Oid relid, bool for_wraparound)
{
char *relname = get_rel_name(relid);
char *nspname = get_namespace_name(get_rel_namespace(relid));
***************
*** 2661,2668 ****
/* Report the command and possible options */
if (vacstmt->vacuum)
snprintf(activity, MAX_AUTOVAC_ACTIV_LEN,
! "autovacuum: VACUUM%s",
! vacstmt->analyze ? " ANALYZE" : "");
else
snprintf(activity, MAX_AUTOVAC_ACTIV_LEN,
"autovacuum: ANALYZE");
--- 2661,2669 ----
/* Report the command and possible options */
if (vacstmt->vacuum)
snprintf(activity, MAX_AUTOVAC_ACTIV_LEN,
! "autovacuum: VACUUM%s%s",
! vacstmt->analyze ? " ANALYZE" : "",
! for_wraparound ? " (to prevent wraparound)" : "");
else
snprintf(activity, MAX_AUTOVAC_ACTIV_LEN,
"autovacuum: ANALYZE");
On Fri, 2008-07-18 at 01:44 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > On Thu, 2008-07-17 at 17:10 -0400, Alvaro Herrera wrote:
> >> I don't like your wording though; it feels too verbose (and you're
> >> losing the ANALYZE in case it's doing both things). How about
> >>
> >> snprintf(activity, MAX_AUTOVAC_ACTIV_LEN,
> >> "autovacuum: VACUUM%s%s", vac
> >> tab->at_doanalyze ? " ANALYZE" : "",
> >> tab->at_wraparound ? " (wraparound)" : "");
>
> > Yes, looks good.
>
> May I suggest "(to prevent wraparound)" or something like that?
> Otherwise, +1.
>
> >> You're not proposing it for 8.3 right?
>
> > I think I am. It's an important diagnostic for your other fix.
>
> I agree, this is important for visibility into what's happening.
> The string isn't getting translated so I don't see any big downside
> to applying the patch in back branches.

Patches for 8.3 and CVS HEAD.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

[ADMIN] Database Link

Hi all,

Like oracle dblink, is it possible to connect two database's in
greenplum??? If yes please pass the command how to create the dblink
to connect two databases.

Regards

Govindarajan

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

Réf. : [pgsql-fr-generale] Probleme Traffic réseau PostgreSQL

Antony,

Comme il n'y avait pas beaucoup de réponse à ton post, j'ai pris mon
courage à 2 mains et ai fait quelques analyses. Pour ne pas avoir à me
perdre dans les sources de PostgreSQL, j'ai installé WireShark sur mon
micro et j'ai regardé les messages échangés entre pgAdmin sur mon micro et
un PostgreSQL sur un serveur Linux.
WireShark est vraiment génial, puisqu'il sait formater en clair les
messages du protocole PostgreSQL :-)
J'en ai déduit ceci sur la taille des messages échangés (hors couches
réseau au dessous) :

1) A l'aller, on a le texte de la requête avec simplement un overhead de 6
octets.

2) Au retour, on a un message (découpé éventuellement en plusieurs paquets
selon la taille) composé de :
- la description des lignes de la table résultat, dont la longueur en
octets est égale à :
7 + ( 19 * nombre de colonnes) + somme des longueurs des noms des
colonnes,
- les lignes de données (voir plus bas),
- 2 commandes "command completion" et "ready for query" représentant 18
octets.
Chaque ligne se compose de :
- une partie fixe de 7 octets,
- la liste des colonnes.
Chaque colonne se compose de :
- une partie fixe de 4 octets,
- la valeur de la colonne.

Tout est donc très logique.

3) Contenu des colonnes :
Pour les colonnes de type CHAR, on trouve le contenu de la colonne (je n'ai
pas fait attention aux questions d'encodage qui peuvent j'imagine avoir un
impact sur la taille physique de chaque caractère). il n'y a pas de
compression, même pour les blancs à droite.
Pour les colonnes de type VARCHAR, on trouve évidemment la longueur réelle
du contenu de la colonne et non sa longueur maximale.
Pour les colonnes BYTEA, les octets "non imprimables" sont représentés par
leur séquence d'escape (\nnn).
Pour les colonnes numériques, la donnée est représentée sous forme de texte
de longueur variable, c'est à dire la suite des chiffres nécessaires à la
représentation du nombre.

4) Les requêtes retournant une ligne et celles retournant plusieurs lignes
semblent avoir la même structure, quelle que soit le nombre de colonnes.

Voici donc ma compréhension de la structure des messages. Elle est
peut-être approximative mais ça peut aider. Quelqu'un a peut-être des
précisions ?

J'imagine que le dialogue entre pgAdmin et PostgreSQL que j'ai observé est
le même que celui des autres clients et drivers disponibles. Quelqu'un
peut-il me confirmer ?

Pour comprendre pourquoi Oracle qui est un peu moins bon sur 1 ligne
devient meilleur sur plusieurs lignes, il faudrait faire ce même exercice
avec Oracle.
A moins que quelqu'un ait une déjà une idée sur la question...

Bon week-end. Philippe.

Stéphane Schildknecht
<stephane.schildknecht@postgr Pour : "'pgsql-fr-generale@postgresql.org'" <pgsql-fr-generale@postgresql.org>
esqlfr.org> cc : antony.resbeut@bull.net
Envoyé par : Objet : [pgsql-fr-generale] Probleme Traffic réseau PostgreSQL
pgsql-fr-generale-owner@postg
resql.org


11/07/2008 00:51

Bonjour,

Je fais suivre un message d'un souscripteur dont les messages n'arrivent
pas jusqu'à la liste... En attendant de comprendre pourquoi ils
n'arrivent pas sur la liste...

Stéphane Schildknecht

###############

Bonjour,

Je fais des tests réseau de comparaison entre Oracle et PostgreSQL et
j'ai des gros écarts...

Lorsque je fais un "select toto from table where titi='x'" alors
le nombre d'octet de la réponse est identique entre Oracle et PostgreSQL
(parfois meilleur sous PostgreSQL).

Si j'enlève la condition "where" alors PostgreSQL est beaucoup plus
bavard qu'Oracle aussi bien en nombre de packet que sur la taille des
packets. Et c'est pire si l'on fais un vidage "select * from table" brutal.
Est-ce normal ?

Pour exemple :
SELECT id_commande FROM COMMANDE (VARCHAR(28))
SGBD |Temps |Octets |Packets size |Avg Mbit/sec |Packets
PostgreSQL|0'00" |1 896 702 |1105 bytes |67.286 |1716
Oracle |0'00" |1 496 151 |846 bytes |26.168 |1768
Informix |0'00" |1 858 862 |999 bytes |22.724 |1859

SELECT date_sign FROM COMMANDE (DATE)
SGBD |Temps |Octets |Packets size |Avg Mbit/sec |Packets
PostgreSQL|0'00" |868 573 |1117 bytes |18.999 |777
Oracle |0'00" |453 126 |876 bytes |8.245 |517
Informix |0'00" |587 446 |1018 bytes |4.882 |577

SELECT id_commande FROM COMMANDE where ID_COMMANDE =
'200706202054510076503-276501' (VARCHAR(28))
SGBD |Temps |Octets |Packets size |Avg Mbit/sec |Packets
PostgreSQL|0'00" |567 |81 bytes |0.024 |7
Oracle |0'00" |975 |139 bytes |0.043 |7
Informix |0'00" |904 |82 bytes |0.046 |11

SELECT * FROM COMMANDE (46255 lignes)

SGBD |Temps |Octets |Packets size |Avg Mbit/sec |Packets
PostgreSQL|0'13" |16 801 515 |1 008 bytes |9.900 |16 653
Oracle |0'08" |06 889 074 |694 bytes |6.752 |09 920
Informix |0'13" |11 481 870 |967 bytes |7.054 |11 867

Merci de votre réponse ou avis.

Antony Resbeut

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

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

Re: [HACKERS] phrase search

Sushant,

the problem of phrase search not in implementation, but in the theoretical
basis. tsearch is query rich and phrase search should support all query
operations, so we need algebra for query operations. We need more time
to investigate this problem, but just have no spare time for this.
If you are interesting, you might think in this direction.

Oleg

On Sat, 19 Jul 2008, Sushant Sinha wrote:

> I looked at query operators for tsquery and here are some of the new
> query operators for position based queries. I am just proposing some
> changes and the questions I have.
>
> 1. What is the meaning of such a query operator?
>
> foo #5 bar -> true if the document has word "foo" followed by "bar" at
> 5th position.
>
> foo #<5 bar -> true if document has word "foo" followed by "bar" with in
> 5 positions
>
> foo #>5 bar -> true if document has word "foo" followed by "bar" after 5
> positions
>
> then some other ways it can be used are
> !(foo #<5 bar) -> true if document never has any "foo" followed by bar
> with in 5 positions.
>
> etc .....
>
> 2. How to implement such query operators?
>
> Should we modify QueryItem to include additional distance information or
> is there any other way to accomplish it?
>
> Is the following list sufficient to accomplish this?
> a. Modify to_tsquery
> b. Modify TS_execute in tsvector_op.c to check new operator
>
> Is there anything needed in rewrite subsystem?
>
> 3. Are these valid uses of the operators and if yes what would they
> mean?
>
> foo #5 (bar & cup)
>
> If no then should the operator be applied to only two QI_VAL's?
>
> 4. If the operator only applies to two query items can we create an
> index such that (foo, bar)-> documents[min distance, max distance]
> How difficult it is to implement an index like this?
>
>
> Thanks,
> -Sushant.
>
> On Thu, 2008-06-05 at 19:37 +0400, Teodor Sigaev wrote:
>>> I can add index support and support for arbitrary distance between
>>> lexeme.
>>> It appears to me that supporting arbitrary boolean expression will be
>>> complicated. Can we pull out something from TSQuery?
>>
>> I don't very like an idea to have separated interface for phrase search. Your
>> patch may be a module and used by people who really wants to have a phrase search.
>>
>> Introducing new operator in tsquery allows to use already existing
>> infrastructure of tsquery such as concatenations (&&, ||, !!), rewrite subsystem
>> etc. But new operation/types specially designed for phrase search makes needing
>> to make that work again.
>>
>
>
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

--
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] Initdb problem on debian mips cobalt: Bus error

Tom Lane wrote:
> Glyn Astill <glynastill@yahoo.co.uk> writes:
>> No. Will recompile with debug info and post back when done.
>
> FWIW, the most likely issue here is the MIPS-specific assembly code in
> src/include/storage/s_lock.h --- I'm not sure how many MIPS platforms
> that's really been exercised on, but it may not work on yours. While
> you're waiting for the rebuild you might try to find a MIPS guru to
> show that code to.

hmm well - lionfish (which is now offline due to a broken power supply)
is actually a cobalt cube too (and is running debian). So if we really
managed to break mipsel it must have happened in the last few months:

http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=lionfish&br=HEAD

Stefan

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