w? Is this possible? Is
there a specific order on which you can count?
Would it be something like: "where" clause first, left to right, followed
by select terms, left to right, and lastly the "order by" clause?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gt; This is just a bad, bad idea. Side-effects in a WHERE-clause function
> are guaranteed to cause headaches. When (not if) it breaks, you get
> to keep both pieces.
I was kind of afraid of that. So, how could one implement such a function
set?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t1.column1 and t2.column2 will only be evaluated once and
that myscore(...) and myrank(...) will all be called before the next
permutation is evaluated?
So, basically, I don't want to recalculate the values for each and every
function call as that would make the system VERY slow.
--
Sent via pgsql
irst come first served" strategy, is there any discontinuity
between the function calls for t1.col1 and t2.col2. Will they all be
called for a particular combination of t1.col1 and t2.col2, in some
unpredictable order before the next row(s) combination is evaluated or
will I have to execute
clause? would that be
called out of order of the select target list? I'm doing a fairly large
amount of processing and doing it once is important.
/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s an important problem of easily mapping programmatic types to a
database.
Anyone think its interesting?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
strategy to the
web guys.
Being able to insert arbitrary named values, and extracting them
similarly, IMHO works "better" and more naturally than some external
aggregate system built on a column. I know it is a little "outside the
box" thinking, what do you think?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
right?
For what its worth, I don't expect you to jump all over this. It really is
a divergence from classic SQL design. I'm not even sure I like it. In
fact, I don't like it, but the argument that you are being forced to
create a second class data storage mechanism or a relational join for data
that is logically in a single relation does cause one to ponder the
problem.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ble to insert arbitrary named values, and extracting them
>> similarly, IMHO works "better" and more naturally than some external
>> aggregate system built on a column. I know it is a little "outside the
>> box" thinking, what do you think?
>>
>>
>
t -hackers at
> large approve of this feature before starting serious coding.
>
> Opinions?
If its fast enough, its a good idea. It could be very helpful in
protecting users data.
>
> --
> Alvaro Herrera
> http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Develo
ll, if there are any spare bits in a block header,
they could be used for the check value.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
eaning a false OK.
Also, regardless of whether or not the block is full, the block is read
and written as a block and that the underlying data unimportant.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
may be in older CPUs, but these days CPUs
are so fast in RAM and a block is very small. On x86 systems, depending on
page alignment, we are talking about two or three pages that will be "in
memory" (They were used to read the block from disk or previously
accessed).
--
Sent
pt
to regenerate the data, then we could certainly optimize the check
algorithm. A simple checksum may be good enough.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
is copied. You
wouldn't want it changing "mid-copy" would you? How is this any less of a
hit than just calculating the checksum?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d almost always lead to configuration issues. As a
methodology for default configuration, it adds flexibility. Also, the
current configuration does not easily take in to consideration the idea
that different databases with different keys can be used from the same
system the same user.
Maybe we need
es, not me. In addition my
application also communicates with other SSL enabled versions of itself.
I think you would agree that a hard coded immutable location for "client"
interface is problematic.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
nctionality you suggest above,
> given support for environment variables:
>
> void PQsetSSLUserCertFileName(char * filename)
> {
>setenv("PGCERTFILE", filename);
> }
>
> void PQsetSSLUserKeyFileName(char *filename)
> {
>setenv("PGKEYFILE", filename);
> }
>
> Or, in perl, $ENV{PGKEYFILE} = $file and so on. It seems
> less intrusive than adding new API calls.
>
> Cheers,
>Steve
Doesn't it make sense that the connection be configured in one place? I
agree with Tom, if it should be done, it should be done in PQconnectdb.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s/client.key
sslcert=/opt/myapp/share/keys/client.crt");
Any comments?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ct. The client
on the other hand, needs to access one or more postgresql servers.
It makes sense that the server keys and credentials be hard coded to its
protected data directory, while the client needs the ability to have
multiple keys.
Think of it this way, a specific lock only takes one key wh
be debated is if we should also somehow allow it
> to be specified in .pgpass for example?
>
I am testing a patch that is currently against the 8.2 series.
It implements in PQconnectdb(...)
sslmode=require sslkey=client.key sslcert=client.crt ssltrustcrt=certs.pem
sslcrl=crl.pem"
BTW: th
sslcrl=fullpath_to_revocation_list
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Here is the SSL patch we discussed previously for 8.3.1.
sslconfig.patch.8.3.1
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
How difficult would it be, and does anyone think it is possible to have a
continuous "restore_command" ala pg_standby running AND have the database
operational in a "read-only" mode?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
hich produces an unusable:
{b5212259-a91f-4dca-a547-4fe89cf2f32c}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
used uuid, and if one
substitutes "uuid()" for "text()" that doesn't work.
The API is less intuitive than the previous incarnation and is, indeed,
more difficult to use.
>
> -Kevin
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
ems is that it is intended to use extracted
XML within a query. The new xpath functionality seems not to be designed
to facilitate this, requiring a pretty arcane query structure to do the
same thing:
select datum from objects where key='GUID' and (xpath(E'foo/bar',
XMLPARSE(CONTENT da
n wrong.
Well, the API is there, it is where, I guess, PostgreSQL is going, but I
think, philosophically, the API needs to see the XML contained within SQL
columns as being able to represent variable and optional columns in object
oriented environments easily. The harder it is to use a feature, the
>
>
> --le 12/03/2003 09:03 -0500, mlw écrivait :
> | I was at a client office reviewing some code. They use MSSQL and I |
> noticed that:
> |
> | select * from table where field = 'blah';
> | gave the same results as:
> | select * from table where field = 'BLah';
> |
> | I was shocked. (a) bec
Actually, as far as I am aware, the header is for metadata, i.e. it is the
place to describe the data being returned. The description of the fields
isn't the actual data retrieved, so it doesn't belong in the body, so it
should go into the header.
> mlw kirjutas E, 31.03.2003 kell 03:43:
>> Give
>
> I can certainly imagine cases for processing where having the field
> names and other metadata up front (maybe add type info, nullable, etc
> instead of just "undefined") would be useful.
>
> here's another question:
>
> If the intention is to use field names as (local) tag names, how will
>
> mlw wrote:
>>
>> Jan Wieck wrote:
>> >[...]
>> >screen? We have a pure BSD alternative that we could even ship with
>> >our distro, time to retire the libreadline hooks.
>> >
>> >
>> I certainly didn't want to open up this can of worms, that's for sure.
>>
>> I have an amount of code that is LG
> [EMAIL PROTECTED] writes:
> We have taken a policy decision to keep the PG core distribution
> (including contrib) straight BSD license --- and in my mind that
> definitely includes not depending on any outside functionality that is
> both (a) essential and (b) not available anywhere as BSD-licen
> On Thursday 29 May 2003 07:26, ow wrote:
>> RH7.3 is a supported distribution for at least 6 months.
>
> By Red Hat, but not necessarily by us.
> That being said:
>
>> Any plans to add
>> Postgres 7.3.3 RPMs for RH7.3?
>
> Yes. Please understand that I only have at my disposal machines
> runn
> Hi,
>
> I'm new in this mailing list and in the world of
> PostGreSQL.
>
> I need to create a C++ application under Windows which
> will use a very huge database...
>
> I was thinking that PostgreSQL could help me to reduce
> the cost of a such software. But i would like to know
> what is the
> Hi,
> could somebody explain me please why following select
> SELECT docid FROM prod.guids
> GROUP BY docid HAVING( COUNT(docid) > 1 )
>
> taking 15 min on 2 Proc Box on 1M rows, where number of duplicates
> around 300K,
> and docid indexed and not null and char(16).
>
> May be I am doin
>From what I recall from the conversation, I would say rename the vsprintf
and the sprintf functions in postgres to pq_vsnprintf and pq_snprintf.
Define a couple macros: (in some common header, pqprintf.h?)
#define snprintf pq_snprintf
#define vsnprintf pq_snprintf
Then just maintain the postgres
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > Please see my posting about using a macro for snprintf. If the
>> current
>> > implementation of snprintf is enough for our existing translation
>> users
>> > we probably don't need to add anything more to it because snprintf
>> will
>> > not be exp
> Tom Lane wrote:
>> [EMAIL PROTECTED] writes:
>> >>> Please see my posting about using a macro for snprintf.
>>
>> > Wasn't the issue about odd behavior of the Win32 linker choosing the
>> wrong
>> > vnsprintf?
>>
>> You're right, the point about the macro was to avoid linker weirdness on
>> Windo
>
>> Maybe we make the assumption that all OS will
>> implement "fd" as an array index
>
> The POSIX spec requires open() to assign fd's consecutively from zero.
> http://www.opengroup.org/onlinepubs/007908799/xsh/open.html
With all due respect, PostgreSQL now runs natively on Win32. Having a
POS
> [EMAIL PROTECTED] writes:
>>> The POSIX spec requires open() to assign fd's consecutively from zero.
>>> http://www.opengroup.org/onlinepubs/007908799/xsh/open.html
>
>> With all due respect, PostgreSQL now runs natively on Win32.
>
> ... using the POSIX APIs that Microsoft so kindly provides.
>
> [EMAIL PROTECTED] writes:
>> That is hardly anything that I would feel comfortable with. Lets break
>> this down into all the areas that are ambiguous:
>
> There isn't anything ambiguous about this, nor is it credible that there
> are implementations that don't follow the intent of the spec.
How
> My copy of APUE says on page 49: "The file descriptor returned by open
> is the lowest numbered unused descriptor. This is used by some
> applications to open a new file on standard input, standard output, or
> standard error."
Yes, I'll restate my questions:
What is meant by "unused?" Is it r
> [EMAIL PROTECTED] wrote:
>> The point is that this *is* silly, but I am at a loss to understand why
>> it
>> isn't a no-brainer to change. Why is there a fight over a trivial change
>> which will ensure that PostgreSQL aligns to the documented behavior of
>> "open()"
>
> (Why characterise this as
I'm a little frustrated
select * from mytable where mystring = 'foo';
Uses an index
select * from mytable where mystring like 'foo';
Does not use an index.
I know Tom is not to excited about this, but I think it is a serious
problem. What really brings me to this is that I just installed 7.4.2
>
> On Wed, 31 Mar 2004 [EMAIL PROTECTED] wrote:
>
>> I'm a little frustrated
>>
>> select * from mytable where mystring = 'foo';
>>
>> Uses an index
>>
>> select * from mytable where mystring like 'foo';
>>
>> Does not use an index.
>>
>> I know Tom is not to excited about this, but I think it is
I know I'm probably being a bomb tosser, but would it be practical to
incorporate, like the serial type, and automatic GUID type?
While I love PostgreSQL, I am frequently forced to deal with Oracle and
MSSQL. While there is a great deal of focus on making PostgreSQL a good
competitor to Oracle, m
About a year or two ago I submitted a configuration patch that allowed
PostgreSQL to be fully configured by postgresql.conf -- enabling data and
configuration to be in separate locations. The idea was that, like most
UNIX systems, that the configuration file could be stored in the /etc
directory (o
> On Thu, 8 Apr 2004 [EMAIL PROTECTED] wrote:
>
>> more flexable configuration based on the idea that configuration and
>> data
>> are in SEPARATE locations is important.
>
> Why is it important and wouldn't it just make it harder to have several
> database clusters (for example with different loca
> Dennis Bjorklund <[EMAIL PROTECTED]> writes:
>> On Thu, 8 Apr 2004 [EMAIL PROTECTED] wrote:
>>> more flexable configuration based on the idea that configuration and
>>> data
>>> are in SEPARATE locations is important.
>
>> Why is it important and wouldn't it just make it harder to have several
>>
> Robert Treat <[EMAIL PROTECTED]> writes:
>> On Thu, 2004-04-08 at 09:49, [EMAIL PROTECTED] wrote:
>>> (2) I would bet that *most* deployments of PostgreSQL only use one
>>> database environment per server, so I'm not even sure that it would be
>>> an
>>> issue for the majority of current or prosp
> Robert Treat <[EMAIL PROTECTED]> writes:
>> On Thu, 2004-04-08 at 09:49, [EMAIL PROTECTED] wrote:
>>> (2) I would bet that *most* deployments of PostgreSQL only use one
database environment per server, so I'm not even sure that it would be
an
>>> issue for the majority of current or prospective u
>
> On Fri, 9 Apr 2004, Christopher Browne wrote:
>>
>> ...Tom ... commented that all of the core developers make extensive use
>> of the notion of having _many_ backends around, and therefore ...
>>
>> Core folk aren't likely to write up patches designed to shoot
>> themselves in the foot this way
year later, I will have
completely forgotten, and of course my notes are no where to be found.
One of the reasons I wrote these mods was so I could create a "standard."
All my PostgreSQL systems have an /etc/postgres/postgresql.conf file. I
sit down and know immediately where to look. I
> Tom Lane wrote:
>> [EMAIL PROTECTED] writes:
>> > I am neither suggesting nor implementing any change in the current
>> default
>> > behavior of PostgreSQL. I am merely adding features that would make it
>> > easier to do things like configure from a centralized directory which
>> is
>> > differe
> I seems to me that the existing situation is actually correct :
>
> The configuration is a property of the initialized database cluster, so
> a logical place for it is in the root of said cluster.
>
> It is *not* a property of the installed binary distribution (e.g
> /usr/
> On Sat, Apr 10, 2004 at 03:53:49PM -0400, [EMAIL PROTECTED] wrote:
>> > The whole idea of having multiple command-line switches to pick config
>> > and data separately bothers me. ISTM this would mostly create great
>> new
>> > opportunities to shoot yourself in the foot (by accidentally picking
> [EMAIL PROTECTED] wrote:
>
>>
>>IMHO my patch can do this in a self
>>documenting way, thus making it easier to do, i.e.
>>
>>postmaster -C /etc/postgres/fundb.conf
>>postmaster -C /etc/postgres/testdb.conf
>>
>>I think that is far more intuitive than:
>>
>>postmaster -D /some/path/who/knows/wher
> [EMAIL PROTECTED] wrote:
>> > Obviously, we need to do something. There are just too many people
>> who
>> > want improvement in this area. The question is what changes to make.
>> >
>> > My personal opinion is that we move the config files in /data/etc, and
>> > allow admins to move that direc
> Alexander Cohen wrote:
>> > Alexander Cohen wrote:
>> >> Has anyone attempted to write a version of pg_ctl in C code? Is it in
>> >> the works anywhere?
>> >
>> > Someone attempted, but never completed it a few months ago, so no, no
>> > one is working on it right now. Use initdb.c as an example
> The only other idea I can think of is to create a new pg_path.conf file.
> It would have the same format as postgresql.conf, but contain
> information about /data location, config file location, and perhaps
> pg_xlog location.
>
> The file would be created by special flags to initdb, and once cre
> [EMAIL PROTECTED] wrote:
>> > The only other idea I can think of is to create a new pg_path.conf
>> file.
>> > It would have the same format as postgresql.conf, but contain
>> > information about /data location, config file location, and perhaps
>> > pg_xlog location.
>> >
>> > The file would be
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Obviously, we need to do something. There are just too many people who
>> want improvement in this area. The question is what changes to make.
[snip]
>
> The whole discussion reminds me quite a bit of Tom Lockhart's patch to
> specify WAL file locati
> Stephan Szabo <[EMAIL PROTECTED]> writes:
>> On Mon, 12 Apr 2004, Bruce Momjian wrote:
>>> I think the major problem with your -C & -D idea is that you require
>>> the
>>> administrator to link the config file and data directory everytime you
>>> start the db, and that might be error-prone.
>
>>
e data dir), but the case for multiple configs with one data dir
>> > seems pretty weak to me, and outweighed by the risk factors.
>>
>> I hear "risk" but what risk?
>
> OK, you look at your postgresql.conf file, and it says the data is in
> /var/data, but the p
> I just had a thought about this: seems like a big part of the objection
> is the risk of specifying -C and -D that don't go together. Well, what
> if they were the same switch? Consider the following simplification of
> the proposed patch:
I was really excited about this idea, then I thought a
> Taking into account that quite a few people have repeatedly stated that
> the components in contrib are considered more supported/recommended than
> similar solutions found on gborg or any other external site, I suggest
> we move the projects dbmirror and dblink to gborg. The rserv contrib
> modu
> Taking into account that quite a few people have repeatedly stated that
the components in contrib are considered more supported/recommended than
similar solutions found on gborg or any other external site, I suggest
we move the projects dbmirror and dblink to gborg. The rserv contrib
module seems
I have been thinking about this subject for a LONG time, and I hope I have
something to contribute.
>
> My question is, "What can we learn from MySQL?" I don't know there is
> anything, but I think it makes sense to ask the question.
>
> Questions I have are:
>
> o Are we marketing ourselve
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> I don't agree with this, since mirrors are web mirrors ... but I do like
>> the 'Contrib' pointing to gborg/projects ...
>
> Yeah, I like the contrib link idea too. Much of the recent discussion
> comes down to gborg not being visible enough.
>
>
A sort of debate started by Bruce about what MySQL does better vs what
PostgreSQL could do, then there was a thread about removing "/contrib"
from the main download, and a few other posts.
I don't think these are unrelated. They all fall under the umbarella of
"How does a new user come to use Post
> WITH LOCATION would be great, That way you could distribute your
> databases across multiple physical disks a lot easier than looking up
> oid's
> and moving the db after it's been created, mounting it over the top of the
> cluster directory
Actually "WITH LOCATION" already exists, but i
> [EMAIL PROTECTED] writes:
>> They say the absolute path is a security issue, I honestly don't see how
>
> Because it allows someone with only CREATEDB privilege to tell the
> backend to write anywhere (that it can write). That's an ability
> that should be reserved to superusers.
I guess I can
I'm sorry to keep bringing this up, but I keep thinking that PostgreSQL is
a PITA to configure. It isn't that I don't know how, or can't read the
documents, it's just that there is too many things that can go wrong or
leave me with the "How does that work?" feeling where I need to test
before I imp
> Greg Stark wrote:
>
>> Jan Wieck <[EMAIL PROTECTED]> writes:
>>
>>> The whole sync() vs. fsync() discussion is in my opinion nonsense at
>>> this
>>> point. Without the ability to limit the amount of files to a reasonable
>>> number,
>>> by employing tablespaces in the form of larger container fi
> On Sun, Apr 25, 2004 at 05:15:19PM -0400, [EMAIL PROTECTED] wrote:
>> (5) Programming languages. We need to make a programming language
>> standard
>> in PostgreSQL. plpgsql is good, but isn't someone working on a Java
>> language. That would be pretty slick.
>
> If there's going to be a single s
>
>> When all is said and done, I think the PostgreSQL project lacks a
>> "Product
>> Management" group which steers the public perception and defines
>> usability. This is something *all* other systems have, including MySQL.
>
> Well, NO, not a chance.
>
> As one of the de-facto heads of our Advoc
> In an attempt to throw the authorities off his trail, [EMAIL PROTECTED]
> transmitted:
>> Is anyone really ready for this sort of commitment?
>
> By that, I presume you mean...
>
> "Are people prepared to stop working on the doubtless useful things
> that they are working on in favor of spending
> Hey,
>
> First of all, who is this? I don't recognize the e-mail, and you haven't
> been signing any of your posts.
I've been posting on hackers on and off for a few years. My name is Mark.
>
>> true, others, however, are very welcoming to direction.
>
> AFAIK, this includes none of our major
This patch incorporates a number of changes suggested by the group. The
purpose of this patch is to move postgresql to a position where all
configuration options are specified in one place. The postgresql.conf file
could completely document a postgresql environment.
It adds this functionality:
T
> Magnus Hagander wrote:
>> >>If you run NTFS, it's still possible to use arbitrary links.
>> >In the Windows
>> >>world, they are called junctions. Microsoft does not provide
>> >a junction tool
>> >>for some reason (perhaps because it's limited to NTFS). A
>> >good tool, free
>> >>and with source
>> >> >We've looked at it before. Apart from anything else I don't think
>> >> >its license is compatible with PostgreSQL's.
>> >>
>> >> Well, people can still use it. We just can't distribute
>> it... We can
>> >> always link to it.
>> >> But unless there is a GUI tool (actually, unless it shows u
> [EMAIL PROTECTED] wrote:
>> >> >> >We've looked at it before. Apart from anything else I don't think
>> >> >> >its license is compatible with PostgreSQL's.
>> >> >>
>> >> >> Well, people can still use it. We just can't distribute
>> >> it... We can
>> >> >> always link to it.
>> >> >> But unless
> [EMAIL PROTECTED] wrote:
>
>> This makes me worried. That's the way we *used* to do things, but the
>> sleazy IP lawyers are looking for anything with which they can create
>> the
>> impression of impropriety. The open source and free projects are ground
>> zero for this crap.
>>
>> We *really* n
> On Wednesday 19 May 2004 00:19, [EMAIL PROTECTED] wrote:
>> > [EMAIL PROTECTED] wrote:
>> >> This makes me worried. That's the way we *used* to do things, but the
>> >> sleazy IP lawyers are looking for anything with which they can create
>> >> the
>> >> impression of impropriety. The open source
> Peter Galbavy wrote:
>
>> [EMAIL PROTECTED] wrote:
>>
>>> I'm probably just being alarmist, but think about some IP lawyer
>>> buying up
>>> the entity that owns the GPL code, and suing end user's of PostgreSQL.
>>
>>
>> You cannot retrospectively change the terms of a license unless the
>> licen
> [EMAIL PROTECTED] wrote:
>> I'm probably just being alarmist, but think about some IP lawyer buying
>> up
>> the entity that owns the GPL code, and suing end user's of PostgreSQL.
>
> You cannot retrospectively change the terms of a license unless the
> licensee agrees to it. If something is rele
>>>You may not distribute this tool without the express written
>>>permission of Mark Russinovich.
>>
>>
>> Then by no means should *any* of that code be included into PostgreSQL.
>> In
>> fact, comments should not even make reference to it.
>
> May I point out that there is a heap of debate about
> [EMAIL PROTECTED] wrote:
>> Imagine this scenario:
>>
>> OpenFoobar is released as GPL. Portions of his code are found in
>> PostgreSQL. The new owner of OpenFoobar is an IP lawyer. They claim
>> ownership of code "derived" from "his" code. There is now a valid, or
>> at least legally arguable, a
>> Ingres is to be released as open source:
>>
>>
>> http://developers.slashdot.org/article.pl?sid=04/05/25/0043219&mode=nested&tid=126&tid=137&tid=163&tid=185&tid=198
>
> Like the article says, I wonder if these is any synergy between the
> products. ie. Can we grab features from their code
Now that it looks like tablespaces will become a practical reality, I want
to suggest some changes in documented procedure and preferred setup. The
reason why I suggest these changes is to enlighten new PostgreSQL users to
the new features and, perhaps, make a more enterprise-familiar environment
f
> [EMAIL PROTECTED] writes:
>> First, we keep the standard PostgreSQL directory the way it has always
>> been with template0, template1, pg_xlog, pg_clog, etc. in the same
>> place.
>> We can refer to this as the "system" directory. This makes sense because
>> all the system level stuff is there. U
> David Blasby <[EMAIL PROTECTED]> writes:
>> I just did another vacuum analyse on the table:
>
> Ah, here we go:
>
>> INFO: "csn_edges": found 0 removable, 16289929 nonremovable row
>> versions in 2783986 pages
>
> That works out to just under 6 rows per 8K page, which wouldn't be too
> bad if th
> Yes, that is generally the case (prefer pg_xlog on separate spindle),
> but no
> need to *forcibly* overcomplicate things if the box has only one
> spindle,
> or if they have only one single RAID'd partition configured. We should
> continue to err on the side of keeping the path to a functional s
> James Robinson wrote:
>
>>>
>>>
>>> Users are primarily, if not stupid, ignorant. They will read the
>>> absolute
>>> minimum needed to achieve a goal and little else. I say this with the
>>> utmost respect, because I and probably everyone else on this group is
>>> guilty of the same thing. So, t
> In the age of inexpensive RAID, tablespaces have more or less lost their
> relevance regarding performance. pgsql's philosophy respects this by
> leaving the storage work up to the OS and disk subsystem. Even having
> the xlog on a different spindle won't help too much; you'll probably be
> bette
ing* from Microsoft, they have very dubious motives and
research practices. They are compulsive liars and everything published by
them is specifically edited to present their agenda.
> They are not read very often...
> If you dedicate drives to services, it's your responsibility to size
>
> "Mohawksoft":
>
>> I forgot to specify that tablepaces should be on separate volumes.
>> (sorry)
>> If all they have is one volume, no worries, but instructing the use of
>> alternate volumes for system and data will improve performance by
>> separating WAL and data operations.
>
> ... and the pl
> [EMAIL PROTECTED] wrote:
>
>>
>>As you can see, it takes a LOT longer. That's because the disk has to do
>> a
>>lot more work, the hardware data path has to carry twice as much data,
>> and
>>you have to manage multiple accesses to a single object, the disk.
>>
>>It doesn't take much imagination
> [EMAIL PROTECTED] wrote:
>
>>You are absolutely wrong on all accounts here. A RAID5 system is slower
>>than a single spindle as it is only as fast as the slowest disk in the
>>stripe and the overhead of the RAID.
>>
> Huh, what kind of controller do you use... Sounds like some "value" IDE
> one.
1 - 100 of 244 matches
Mail list logo
