I see this in pgbench.c:
/* return false iff client should be disconnected */
static bool
doCustom(CState *st, instr_time *conn_time)
I think you need to increase the verbosity of the error messages when
you're working on this code, because when I compile I get a slew of these
Christophe Pettus x...@thebuild.com wrote:
Summary:Add a string key space to the advisory lock functionality.
Why aren't you satisfied with hashtext('foo') ?
The restriction comes from LOCKTAG struct, in which
we can use only 3 * uint32 and 1 * uint16 for lock descriptor.
Regards,
---
Andrew Gierth wrote:
James == James Pye li...@jwp.name writes:
James Is the new date_recv() constraint actually correct?
No, it's not:
Oops, you're right. The check is indeed confusing julian day numbers,
with epoch at 23th of Nov 4714 BC, with postgres-reckoning day numbers,
with epoch
2009/10/26 David Fetter da...@fetter.org:
Not being any kind of attorney, and assuming the Red Hat lawyers
are pretty much on our side,
They're not really. They're just interested in doing things the right
way for Redhat users (which is fine - that's what they're paid for).
I'll just say
Hi, All
I faced this odd situation when I was migrating my data from 8.3.7 to
8.4.1. After setting up instance, applying schema dump w/o and indexes
and loading data I was trying to create this indexes and got a lot of
multiply messages picksplit method for column 2 of index ... doesn't
support
Tom Lane escribió:
Robert Haas robertmh...@gmail.com writes:
This seems like it could potentially introduce a performance
regression, but the current behavior is so bizarre that it seems like
we should still change it.
Yeah, it could definitely run slower than the existing code ---
On Sun, 2009-10-25 at 22:48 -0400, Tom Lane wrote:
Otherwise I'm not sure it matters.
If that were true, why did Red Hat lawyers do this?
ISTM we should apply to OSI for approval of our licence, so we can then
refer to it as the PostgreSQL licence. That then avoids any situation
that might
On Mon, Oct 26, 2009 at 12:46 AM, Josh Berkus j...@agliodbs.com wrote:
On 10/25/09 5:33 PM, Robert Haas wrote:
Greg believes that it
isn't politically feasible to change the default postgresql.conf, now
or perhaps ever. I notice that he didn't say that he thinks it's a
bad idea. So he has
Christophe Pettus wrote:
API Changes:
Overloading the various advisory lock functions to take a suitable
string type (varchar(64)?) in addition to the bigint / 2 x int
variations. As with the bigint / 2 x int forms, this string
namespace would be disjoint from the other key spaces.
I
On Mon, Oct 26, 2009 at 12:18 AM, Greg Smith gsm...@gregsmith.com wrote:
On Sun, 25 Oct 2009, Robert Haas wrote:
I especially don't believe that it will ever support SET PERSISTENT, which
I believe to be a feature a lot of people want.
It actually makes it completely trivial to implement.
On Mon, Oct 26, 2009 at 1:08 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, 2009-10-25 at 22:48 -0400, Tom Lane wrote:
Otherwise I'm not sure it matters.
If that were true, why did Red Hat lawyers do this?
Because they categorise licences to help their users. It's just a label.
ISTM
On Thu, Oct 22, 2009 at 7:16 PM, Joshua D. Drake j...@commandprompt.comwrote:
On Thu, 2009-10-22 at 14:28 -0200, João Eugenio Marynowski wrote:
Hi
Repair? Not likely. Get past? Maybe.
I don't know how valuable your data is, but I've performed data recovery on
tens of PG databases
2009/10/25 Simon Riggs si...@2ndquadrant.com:
On Mon, 2009-10-19 at 17:48 +0100, Dean Rasheed wrote:
This is a WIP patch to replace the after-trigger queues with TID bitmaps
to prevent them from using excessive amounts of memory. Each round of
trigger executions is a modified bitmap heap
2009/10/25 Jeff Davis pg...@j-davis.com:
On Mon, 2009-10-19 at 17:48 +0100, Dean Rasheed wrote:
This is a WIP patch to replace the after-trigger queues with TID bitmaps
to prevent them from using excessive amounts of memory. Each round of
trigger executions is a modified bitmap heap scan.
On Mon, 2009-10-26 at 13:28 +, Dean Rasheed wrote:
It works for all kinds of trigger events,
and is intended as a complete drop-in replacement for the after
triggers queue.
All of those seem false in the general case. What will you do?
At this point I'm looking for more feedback as
On Mon, 2009-10-26 at 13:13 +, Dave Page wrote:
ISTM we should apply to OSI for approval of our licence, so we can then
refer to it as the PostgreSQL licence. That then avoids any situation
that might allow someone to claim some injunctive relief of part of the
licence because of it
On Mon, Oct 26, 2009 at 1:54 AM, Christophe Pettus x...@thebuild.com wrote:
Greetings,
I'd like to propose a potential patch, and wanted to get preliminary
feedback on it before I started looking into the design.
Summary: Add a string key space to the advisory lock functionality.
On Mon, 2009-10-26 at 09:04 -0400, Robert Haas wrote:
On Mon, Oct 26, 2009 at 12:46 AM, Josh Berkus j...@agliodbs.com wrote:
On 10/25/09 5:33 PM, Robert Haas wrote:
Greg believes that it
isn't politically feasible to change the default postgresql.conf, now
or perhaps ever. I notice that
On Mon, Oct 26, 2009 at 1:47 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-10-26 at 13:13 +, Dave Page wrote:
ISTM we should apply to OSI for approval of our licence, so we can then
refer to it as the PostgreSQL licence. That then avoids any situation
that might allow
Robert Haas escribió:
On Mon, Oct 26, 2009 at 12:18 AM, Greg Smith gsm...@gregsmith.com wrote:
It actually makes it completely trivial to implement. SET PERSISTENT can
now write all the changes out to a new file in the include directory. Just
ship the database with a persistent.conf in
Christophe Pettus x...@thebuild.com writes:
I'd like to propose a potential patch, and wanted to get preliminary
feedback on it before I started looking into the design.
Summary:Add a string key space to the advisory lock functionality.
Your chances of making the LOCKTAG struct bigger
Alvaro Herrera alvhe...@commandprompt.com writes:
Maybe SET PERSISTENT needs to go back to postgresql.conf, add an
automatic comment # overridden in persistent.conf and put a comment
marker in front of the original line. That way the user is led to the
actual authoritative source.
Doesn't
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Yeah, it could definitely run slower than the existing code --- in
particular the combination of all three (FOR UPDATE ORDER BY LIMIT)
would tend to become a seqscan-and-sort rather than possibly just
reading one end of an
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Maybe SET PERSISTENT needs to go back to postgresql.conf, add an
automatic comment # overridden in persistent.conf and put a comment
marker in front of the original line. That way the user is led to the
actual
Alvaro Herrera wrote:
Christophe Pettus wrote:
API Changes:
Overloading the various advisory lock functions to take a suitable
string type (varchar(64)?) in addition to the bigint / 2 x int
variations. As with the bigint / 2 x int forms, this string
namespace would be disjoint from the
On Mon, Oct 26, 2009 at 9:51 AM, Peter Eisentraut pete...@gmx.net wrote:
On Mon, 2009-10-26 at 09:04 -0400, Robert Haas wrote:
On Mon, Oct 26, 2009 at 12:46 AM, Josh Berkus j...@agliodbs.com wrote:
On 10/25/09 5:33 PM, Robert Haas wrote:
Greg believes that it
isn't politically feasible to
On Mon, Oct 26, 2009 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Yeah, it could definitely run slower than the existing code --- in
particular the combination of all three (FOR UPDATE ORDER BY LIMIT)
would tend to become
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Personally I think this is just a matter of usage. If you want to use
SET PERSISTENT, don't set values manually in postgresql.conf.
I agree, except that some things are defined in postgresql.conf by
initdb and you probably
Robert Haas robertmh...@gmail.com writes:
What am I missing here?
You're still attacking the wrong straw man. Whether the file contains a
lot of commentary by default is NOT the problem, and removing the
commentary is NOT the solution.
regards, tom lane
--
Sent via
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribi�:
Personally I think this is just a matter of usage. If you want to use
SET PERSISTENT, don't set values manually in postgresql.conf.
I agree, except that some things are defined in postgresql.conf by
Alvaro Herrera alvhe...@commandprompt.com writes:
(But to me this also says that SET PERSISTENT has to go over
00initdb.conf and add a comment mark to the setting.)
Why? As you yourself pointed out, pg_settings will show exactly where
the active value came from. Moreover, should we then
Heikki == Heikki Linnakangas heikki.linnakan...@enterprisedb.com
writes:
Heikki Oops, you're right. The check is indeed confusing julian day
Heikki numbers, with epoch at 23th of Nov 4714 BC, with
Heikki postgres-reckoning day numbers, with epoch at 1th of Jan
Heikki 2000. Thanks, will
Robert Haas robertmh...@gmail.com wrote:
I realize that the current file format is an old and familiar
friend; it is for me, too. But I think it's standing in the way of
progress. Being able to type a SQL command to update postgresql.conf
would be more substantially convenient than logging
Greg Smith gsm...@gregsmith.com writes:
People who want to continue managing just the giant postgresql.conf are
free to collapse the initdb.conf back into the larger file instead. If we
wanted to make that transition easier, an option to initdb saying do
things the old way might make
On Mon, 26 Oct 2009, Alvaro Herrera wrote:
some things are defined in postgresql.conf by initdb and you probably
want to be able to change them by SET PERSISTENT anyway (e.g.
lc_messages, listen_addresses, shared_buffers)
An obvious next step once the directory parsing is committed is to
On Mon, 26 Oct 2009, Alvaro Herrera wrote:
But to me this also says that SET PERSISTENT has to go over
00initdb.conf and add a comment mark to the setting.
Now you're back to being screwed if the server won't start because of your
change, because you've lost the original working setting.
I
Greg Smith gsm...@gregsmith.com writes:
I think the whole idea of making tools find duplicates and comment them
out as part of making their changes is fundamentally broken, and it's just
going to get worse when switching to use more config files.
Quite. There seems to me to be a whole lot
On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
ISTM we should apply to OSI for approval of our licence, so we can then
refer to it as the PostgreSQL licence.
IMHO and not being a lawyer, this is the only reason for anyone to
think in change our license i think...
On Mon, Oct 26, 2009 at 3:36 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
ISTM we should apply to OSI for approval of our licence, so we can then
refer to it as the PostgreSQL licence.
IMHO and not being a
On Mon, 26 Oct 2009, Tom Lane wrote:
BTW, why do we actually need an includedir mechanism for this?
A simple include of a persistent.conf file seems like it would be
enough.
Sure, you could do it that way. This patch is more about elegance rather
than being strictly required. The general
On Mon, 26 Oct 2009, Tom Lane wrote:
When and if there is some evidence of people actually getting confused,
we could consider trying to auto-comment-out duplicate settings. But
I've never heard of any other tool doing that, and fail to see why we
should think Postgres needs to.
It's what
On sön, 2009-10-25 at 23:48 +, Roger Leigh wrote:
Just for reference, this is what the output looks like (abridged)
using the attached patch. Should display fine if your mail client handles
UTF-8 messages correctly:
rleigh=# \l
List of databases
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 26, 2009 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
One problem with this is that there isn't any good way for someone to
get back the old behavior if they want to. Which might be a perfectly
reasonable thing, eg if they know that no
On Mon, Oct 26, 2009 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith gsm...@gregsmith.com writes:
People who want to continue managing just the giant postgresql.conf are
free to collapse the initdb.conf back into the larger file instead. If we
wanted to make that transition easier,
I wrote:
Robert Haas robertmh...@gmail.com writes:
Could the desired behavior be obtained using a CTE?
Nope, we push FOR UPDATE into WITHs too. I don't really see any way to
deal with this without some sort of semantic changes.
... although on reflection, I'm not sure *why* we push FOR
On Oct 24, 2009, at 10:44 AM, Peter Eisentraut wrote:
More detail is available in the Release Notes included with each
alpha:
http://developer.postgresql.org/pgdocs/postgres/release-8.5.html
That seems to just have alpha1 at the moment.
Best,
David
--
Sent via pgsql-hackers mailing list
On Sun, Oct 25, 2009 at 9:05 AM, Robert Haas robertmh...@gmail.com wrote:
Arguably, you would expect parameters set using this syntax to be
stored similar to reloptions - that is, as text[]. But as we're going
to need these values multiple times per table to plan any non-trivial
query, I
On Mon, Oct 26, 2009 at 10:40 AM, Dave Page dp...@pgadmin.org wrote:
On Mon, Oct 26, 2009 at 3:36 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
ISTM we should apply to OSI for approval of our licence, so we can
On Mon, Oct 26, 2009 at 4:15 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Mon, Oct 26, 2009 at 10:40 AM, Dave Page dp...@pgadmin.org wrote:
On Mon, Oct 26, 2009 at 3:36 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs
Dave Page dp...@pgadmin.org writes:
On Mon, Oct 26, 2009 at 4:15 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
to tell someone we no longer label our license as simplified BSD but
as MIT is, in the eyes and mind of users, changing the license... even
if the wording doesn't change...
Howdy,
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command. And from Tom's
comments, it looks like it was committed in such a way to make such
extensions
Howdy,
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command. And from Tom's
comments, it looks like it was committed in such a way to make such
extensions
On Mon, Oct 26, 2009 at 4:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Mon, Oct 26, 2009 at 4:15 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
to tell someone we no longer label our license as simplified BSD but
as MIT is, in the eyes and mind of
On Mon, 2009-10-26 at 09:14 -0400, Jonah H. Harris wrote:
On Thu, Oct 22, 2009 at 7:16 PM, Joshua D. Drake
j...@commandprompt.com wrote:
On Thu, 2009-10-22 at 14:28 -0200, João Eugenio Marynowski
wrote:
Hi
Repair? Not likely. Get past? Maybe.
I
On Mon, 2009-10-26 at 13:41 +, Dean Rasheed wrote:
I did a quick bit of testing, and I think that there is a
locking/concurrency problem :-(
Unfortunately I can't reproduce the problem on my machine; it always
passes.
If you have a minute, can you try to determine if the problem can happen
2009/10/26 Simon Riggs si...@2ndquadrant.com:
On Mon, 2009-10-26 at 13:28 +, Dean Rasheed wrote:
It works for all kinds of trigger events,
and is intended as a complete drop-in replacement for the after
triggers queue.
All of those seem false in the general case. What will you do?
At
2009/10/25 Roger Leigh rle...@codelibre.net:
rleigh=# \l
List of databases
Name │ Owner │ Encoding │ Collation │ Ctype │ Access
privileges
─┼──┼──┼─┼─┼───
Le samedi 24 octobre 2009 01:04:19, Josh Berkus a écrit :
Cedric,
ase is a table containing 29 GB of bytea in a database of 52 GB. Every
row on the 29GB table is grab only few times. And it will just renew OS
cache memory every time (the server have only 8GB of ram).
So when I remove
On Sun, Oct 25, 2009 at 9:37 AM, 노홍찬 falls...@cs.yonsei.ac.kr wrote:
What I am trying to do now is to examine the real dirty portion of buffer
pages to be flushed like the following.
page 1
-
| | dportion1 (real dirty portion 1) ranges between 20 ~ 80
| dportion1
2009/10/26 Jeff Davis pg...@j-davis.com:
On Mon, 2009-10-26 at 13:41 +, Dean Rasheed wrote:
I did a quick bit of testing, and I think that there is a
locking/concurrency problem :-(
Unfortunately I can't reproduce the problem on my machine; it always
passes.
That's odd. It happens
On Mon, Oct 26, 2009 at 10:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
What am I missing here?
You're still attacking the wrong straw man. Whether the file contains a
lot of commentary by default is NOT the problem, and removing the
commentary is NOT
Greg Stark gsst...@mit.edu writes:
While i agree this looks nicer I wonder what it does to things like
excel/gnumeric/ooffice auto-recognizing table layouts and importing
files. I'm not sure our old format was so great for this so maybe this
is actually an improvement I'm asking for.
Yeah.
On Mon, Oct 26, 2009 at 9:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-10-26 at 13:28 +, Dean Rasheed wrote:
It works for all kinds of trigger events,
and is intended as a complete drop-in replacement for the after
triggers queue.
All of those seem false in the general
On Sun, Oct 25, 2009 at 7:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
All that we have to do to fix the first one is to put the LockRows node
below the Limit node instead of above it. The solution for the second
one is to also put LockRows underneath the Sort node, and to regard its
output as
Greg Stark gsst...@mit.edu writes:
On Sun, Oct 25, 2009 at 7:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
All that we have to do to fix the first one is to put the LockRows node
below the Limit node instead of above it. The solution for the second
one is to also put LockRows underneath the Sort
On Sat, Oct 24, 2009 at 6:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we should have an explicit include-directory directive, and the
reason I think so is that it makes it fairly easy for the user to
control the relative precedence of the manual settings (presumed to
still be kept in
On Mon, Oct 26, 2009 at 7:06 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Maybe SET PERSISTENT needs to go back to postgresql.conf, add an
automatic comment # overridden in persistent.conf and put a comment
marker in front of the original line. That way the user is led to the
actual
On Mon, Oct 26, 2009 at 7:25 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I agree, except that some things are defined in postgresql.conf by
initdb and you probably want to be able to change them by SET PERSISTENT
anyway (e.g. lc_messages, listen_addresses, shared_buffers)
These things
On Mon, 2009-10-26 at 10:19 -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Maybe SET PERSISTENT needs to go back to postgresql.conf, add an
automatic comment # overridden in persistent.conf and put a comment
marker in front of the original line. That way the user
On Mon, Oct 26, 2009 at 12:55 PM, Joshua D. Drake j...@commandprompt.comwrote:
This reply is wholly inappropriate for a Pg list. We are here to help
people. If you have a consultancy, please feel free to list that but any
discussion of rates is just plain rude. Please use better discretion in
David E. Wheeler wrote:
Howdy,
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command. And from Tom's
comments, it looks like it was committed in such a way to
Hello
I have a idea about migration of outer (psql) variables, and custom
shell variables.
some like:
psql --allow_custom_variables --table_name=mytable
inside psql we should to use :table_name variable with mytable as content.
then we can use syntax
do (table_name varchar) $$
begin
raise
Andrew Dunstan and...@dunslane.net writes:
David E. Wheeler wrote:
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command.
It was discussed and rejected, at
Why aren't you satisfied with hashtext('foo') ?
Collisions, mostly.
The restriction comes from LOCKTAG struct, in which
we can use only 3 * uint32 and 1 * uint16 for lock descriptor.
Yeah, that's a pretty hard limit. NM, we'll have to figure out some way
around it.
--Josh Berkus
--
Robert Haas robertmh...@gmail.com writes:
I'm not sure whether you're saying that I'm bringing this issue up in
the wrong thread, or whether you disagree with the basic suggestion.
The former --- whether we want to trim down the commentary in
postgresql.conf seems to me to have nothing to do
On 10/26/09 9:01 AM, Robert Haas wrote:
(BTW, why do we actually need an includedir mechanism for this?
A simple include of a persistent.conf file seems like it would be
enough.)
I was starting to wonder that, too.
Different issue, really, which is that some people (including me) would
On mån, 2009-10-26 at 09:08 -0700, David E. Wheeler wrote:
On Oct 24, 2009, at 10:44 AM, Peter Eisentraut wrote:
More detail is available in the Release Notes included with each
alpha:
http://developer.postgresql.org/pgdocs/postgres/release-8.5.html
That seems to just have alpha1 at
Jonah H. Harris jonah.har...@gmail.com wrote:
Joshua D. Drake j...@commandprompt.comwrote:
This reply is wholly inappropriate for a Pg list. We are here to
help people. If you have a consultancy, please feel free to list
that but any discussion of rates is just plain rude. Please use
better
On Oct 26, 2009, at 1:16 PM, Pavel Stehule wrote:
I have a idea about migration of outer (psql) variables, and custom
shell variables.
some like:
psql --allow_custom_variables --table_name=mytable
inside psql we should to use :table_name variable with mytable as
content.
then we can use
On Oct 26, 2009, at 1:21 PM, Tom Lane wrote:
A lambda facility would require being able to pass arguments and
return
results, which we intentionally left out of DO to keep it simple. By
the time you add all that notation, it's far from clear that you
shouldn't just define a function.
Well
On Mon, Oct 26, 2009 at 8:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
(BTW, why do we actually need an includedir mechanism for this?
A simple include of a persistent.conf file seems like it would be
enough.)
Actually I think the include directory came from another use case
which we've also
On Mon, Oct 26, 2009 at 4:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm not sure whether you're saying that I'm bringing this issue up in
the wrong thread, or whether you disagree with the basic suggestion.
The former --- whether we want to trim down
2009/10/26 David E. Wheeler da...@kineticode.com:
On Oct 26, 2009, at 1:16 PM, Pavel Stehule wrote:
I have a idea about migration of outer (psql) variables, and custom
shell variables.
some like:
psql --allow_custom_variables --table_name=mytable
inside psql we should to use :table_name
On Mon, Oct 26, 2009 at 1:40 PM, Josh Berkus j...@agliodbs.com wrote:
Different issue, really, which is that some people (including me) would
like to break up PostgreSQL configuration into 7 or 8 files based on
functional area (e.g. memory.conf, logging.conf, custom_options.conf
...). I do
+1
Would you make it +2?
--
dim
Le 26 oct. 2009 à 19:15, Greg Stark gsst...@mit.edu a écrit :
On Sat, Oct 24, 2009 at 6:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we should have an explicit include-directory directive, and
the
reason I think so is that it makes it fairly easy
Hi,
we have come across a problem where we need an inverted index,
an array of IDs ordered by another condition. We came up
with this scheme:
-- final inverted index
CREATE TABLE product.t_product_inv (
wordtextprimary key not null,
ids bigint[]
);
-- transition
On Mon, 26 Oct 2009, Greg Stark wrote:
Actually I think the include directory came from another use case
which we've also discussed. Namely modules which need some
configuration themselves. So for example when you install PostGIS it
could drop a postgis.conf in the directory which you could
Hi,
I tried to utilize the advertised feature of 8.4, the
separate fillfactor setting for the toast table.
o=# create table t2 (id serial primary key, t text) with (fillfactor=75,
toast.fillfactor=60);
NOTICE: CREATE TABLE will create implicit sequence t2_id_seq for
serial column t2.id
ERROR:
On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.
I see, because `DO` is a statement, not an expression. Thus arguments
don't really make much sense (I wish it was an expression!).
David E. Wheeler wrote:
On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.
I see, because `DO` is a statement, not an expression. Thus arguments
don't really make much sense (I wish
Robert,
As to (1), my thought is to add two new float8 columns to
pg_tablespace. The naming is a little awkward, because
random_page_cost and seq_page_cost would not fit with our (rather odd)
convention for naming system catalog columns. I'm tempted to call
them spcrandompagecost and
Boszormenyi Zoltan wrote:
Hi,
I tried to utilize the advertised feature of 8.4, the
separate fillfactor setting for the toast table.
o=# create table t2 (id serial primary key, t text) with (fillfactor=75,
toast.fillfactor=60);
NOTICE: CREATE TABLE will create implicit sequence
On Mon, 2009-10-26 at 19:11 -0300, Alvaro Herrera wrote:
We explicitely disallow setting fillfactor on toast tables.
So should that be made more clear in the documentation?
http://www.postgresql.org/docs/8.4/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS
Looking at that page
Greg,
This actually seems like a bad idea to me.
You write your tool your way, I'll write my tool mine. We'll see which
one works the best in the field.
Well you're assuming there's only one tool generating this config? We
have at least two and possibly more. initdb generates an initial
Boszormenyi Zoltan z...@cybertec.at writes:
INSERT INTO product.t_product_inv
SELECT word, array_accum_1(price, id) FROM product.t_product_inv0
GROUP BY word ORDER BY word, price NULLS FIRST, id;
However, I get an error:
ERROR: column t_product_inv0.price must appear in the GROUP BY clause
2009/10/26 David E. Wheeler da...@kineticode.com:
On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.
I see, because `DO` is a statement, not an expression. Thus arguments don't
really
On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
Greg Stark gsst...@mit.edu writes:
While i agree this looks nicer I wonder what it does to things like
excel/gnumeric/ooffice auto-recognizing table layouts and importing
files. I'm not sure our old format was so great for this so
Roger Leigh rle...@codelibre.net writes:
On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
Yeah. We can do what we like with the UTF8 format but I'm considerably
more worried about the aspect of making random changes to the
plain-ASCII output.
I checked (using strace)
gnumeric (via
Pavel Stehule wrote:
2009/10/26 David E. Wheeler da...@kineticode.com:
On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.
I see, because `DO` is a statement, not an
On Mon, Oct 26, 2009 at 07:19:24PM -0400, Tom Lane wrote:
Roger Leigh rle...@codelibre.net writes:
On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
Yeah. We can do what we like with the UTF8 format but I'm considerably
more worried about the aspect of making random changes to the
1 - 100 of 118 matches
Mail list logo