Christophe Pettus 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,
---
ITAGAKI Takahiro
NT
Andrew Gierth wrote:
>> "James" == James Pye 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 at
2009/10/26 David Fetter :
> 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 we're more MIT-li
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 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 --- in
> particul
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 allo
On Mon, Oct 26, 2009 at 12:46 AM, Josh Berkus 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 come up w
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.
On Mon, Oct 26, 2009 at 12:18 AM, Greg Smith 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. SET PERSISTENT
On Mon, Oct 26, 2009 at 1:08 PM, Simon Riggs 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 we should apply t
On Thu, Oct 22, 2009 at 7:16 PM, Joshua D. Drake wrote:
> 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 suffering from both hard
2009/10/25 Simon Riggs :
> 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.
>
> This is
2009/10/25 Jeff Davis :
> 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.
>
> Can you ple
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 feedba
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
On Mon, Oct 26, 2009 at 1:54 AM, Christophe Pettus 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.
>
> Rationale:
>
> R
On Mon, 2009-10-26 at 09:04 -0400, Robert Haas wrote:
> On Mon, Oct 26, 2009 at 12:46 AM, Josh Berkus 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 di
On Mon, Oct 26, 2009 at 1:47 PM, Simon Riggs 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 someone to claim
Robert Haas escribió:
> On Mon, Oct 26, 2009 at 12:18 AM, Greg Smith 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 there that looks
Christophe Pettus 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 for this are non
Alvaro Herrera 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 that require the same A
Alvaro Herrera 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 index. However, I
Tom Lane escribió:
> Alvaro Herrera 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.
>
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 disjoi
On Mon, Oct 26, 2009 at 9:51 AM, Peter Eisentraut wrote:
> On Mon, 2009-10-26 at 09:04 -0400, Robert Haas wrote:
>> On Mon, Oct 26, 2009 at 12:46 AM, Josh Berkus wrote:
>> > On 10/25/09 5:33 PM, Robert Haas wrote:
>> >> Greg believes that it
>> >> isn't politically feasible to change the default
On Mon, Oct 26, 2009 at 10:30 AM, Tom Lane wrote:
> Alvaro Herrera 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 p
Alvaro Herrera 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 want to be able to
Robert Haas 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 pgsql-hackers mailing
Tom Lane escribió:
> Alvaro Herrera 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
Alvaro Herrera 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 conclude that any
edit to any
> "Heikki" == Heikki Linnakangas
> 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 fix.
Which reminds me:
Robert Haas 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 in as root,
> usin
Greg Smith 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 sense. I think the
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 chan
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 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 of solving of hypot
On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs 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...
even in the case bot
On Mon, Oct 26, 2009 at 3:36 PM, Jaime Casanova
wrote:
> On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs 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 anyo
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 co
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 p
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 database
Robert Haas writes:
> On Mon, Oct 26, 2009 at 10:30 AM, Tom Lane 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 concurrent update is supposed
>>
On Mon, Oct 26, 2009 at 11:07 AM, Tom Lane wrote:
> Greg Smith 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
I wrote:
> Robert Haas 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 UPDATE into
WITHs. T
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 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 don't want to inject u
On Mon, Oct 26, 2009 at 10:40 AM, Dave Page wrote:
> On Mon, Oct 26, 2009 at 3:36 PM, Jaime Casanova
> wrote:
>> On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs wrote:
>>>
>>> ISTM we should apply to OSI for approval of our licence, so we can then
>>> refer to it as the PostgreSQL licence.
>>>
>>
>
On Mon, Oct 26, 2009 at 4:15 PM, Jaime Casanova
wrote:
> On Mon, Oct 26, 2009 at 10:40 AM, Dave Page wrote:
>> On Mon, Oct 26, 2009 at 3:36 PM, Jaime Casanova
>> wrote:
>>> On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs wrote:
ISTM we should apply to OSI for approval of our licence, so
Dave Page writes:
> On Mon, Oct 26, 2009 at 4:15 PM, Jaime Casanova
> 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...
> So what do you suggest? Burying o
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 po
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 po
On Mon, Oct 26, 2009 at 4:25 PM, Tom Lane wrote:
> Dave Page writes:
>> On Mon, Oct 26, 2009 at 4:15 PM, Jaime Casanova
>> 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 wordi
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
> wrote:
> 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 ho
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 happe
2009/10/26 Simon Riggs :
> 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
2009/10/25 Roger Leigh :
> rleigh=# \l
> List of databases
> Name │ Owner │ Encoding │ Collation │ Ctype │ Access
> privileges
> ─┼──┼──┼─┼─┼───
> merkelpb
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
On Sun, Oct 25, 2009 at 9:37 AM, 노홍찬 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 :
> 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 every time on
On Mon, Oct 26, 2009 at 10:47 AM, Tom Lane wrote:
> Robert Haas 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.
Wow, not only am
Greg Stark 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. We can do wha
On Mon, Oct 26, 2009 at 9:46 AM, Simon Riggs 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 case. What
On Sun, Oct 25, 2009 at 7:34 PM, Tom Lane 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 unsorted so that
Greg Stark writes:
> On Sun, Oct 25, 2009 at 7:34 PM, Tom Lane 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
>>
On Sat, Oct 24, 2009 at 6:55 PM, Tom Lane 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 postgresql.conf)
On Mon, Oct 26, 2009 at 7:06 AM, Alvaro Herrera
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 authoritative source.
On Mon, Oct 26, 2009 at 7:25 AM, Alvaro Herrera
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 should go into a postgr
On Mon, 2009-10-26 at 10:19 -0400, Tom Lane wrote:
> Alvaro Herrera 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
> >
On Mon, Oct 26, 2009 at 12:55 PM, Joshua D. Drake wrote:
> 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
> the future.
>
Per
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 m
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
rais
Andrew Dunstan 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 least for now.
> 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
--
S
Robert Haas 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 with what's
being disc
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)
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 a
>>>"Jonah H. Harris" wrote:
> Joshua D. Drake wrote:
>
>> 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 the future.
>>
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 us
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 s
On Mon, Oct 26, 2009 at 8:07 AM, 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.)
Actually I think the include directory came from another use case
which we've also discussed. Namely mo
On Mon, Oct 26, 2009 at 4:33 PM, Tom Lane wrote:
> Robert Haas 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.co
2009/10/26 David E. Wheeler :
> 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 var
On Mon, Oct 26, 2009 at 1:40 PM, Josh Berkus 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 this with my A
+1
Would you make it +2?
--
dim
Le 26 oct. 2009 à 19:15, Greg Stark a écrit :
On Sat, Oct 24, 2009 at 6:55 PM, Tom Lane 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 relati
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 table
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 th
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 s
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 br
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 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
> or be u
2009/10/26 David E. Wheeler :
> 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 s
On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
> Greg Stark 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
Roger Leigh 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 libgda and
Pavel Stehule wrote:
2009/10/26 David E. Wheeler :
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 argume
On Mon, Oct 26, 2009 at 07:19:24PM -0400, Tom Lane wrote:
> Roger Leigh 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-A
On Mon, Oct 26, 2009 at 3:05 PM, Josh Berkus wrote:
> I'm thinking an array, in case we want to make other tablespace cost
> parameters in the future.* Or, better, whatever structure we're
> currently using for ROLEs.
>
> (* for example, if someone does manage a filesystem with a separate
> cache
1 - 100 of 118 matches
Mail list logo
