Re: [GENERAL] General performance/load issue
Actually, this is because I changed sort_mem to 4 Mb as asked by Robert. I removed this setting.. Gaëtan Le 26/11/11 18:58, « Tomas Vondra » t...@fuzzy.cz a écrit : Dne 26.11.2011 18:08, Gaëtan Allart napsal(a): UhmŠ I'm seeing dozens and dozens of temporary file creations in logs : LOG: temporary file: path base/pgsql_tmp/pgsql_tmp15388.1399, size 23912 LOG: temporary file: path base/pgsql_tmp/pgsql_tmp15388.211, size 2761788 LOG: temporary file: path base/pgsql_tmp/pgsql_tmp13772.3747, size 27188 LOG: temporary file: path base/pgsql_tmp/pgsql_tmp13772.2639, size 2749672 LOG: temporary file: path base/pgsql_tmp/pgsql_tmp15388.1053, size 24276 LOG: temporary file: path base/pgsql_tmp/pgsql_tmp15388.452, size 2948712 Please, add timestamp to log_line_prefix so that we know how frequently that happens. Anyway the output is a bit strange. It's writing a lot of temp files that are significantly smaller (about 3MB) than work_mem (128MB). Tomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] CPU move
Am 26.11.2011 19:18, schrieb Carlos Henrique Reimer: Hi, We're planning to move our postgreSQL database from one CPU box to another box. I'm considering an alternative procedure for the move as the standard one (pg_dump from the old, copy dump to the new box, psql to restore in the new) will take about 10 hours to complete. The ideia is installing the same Linux and PostgreSQL versions in the new box and copy the entire database cluster directory from the old to the new one using the scp Linux command. If you are using the same architecture you could use the warm-standby procedure for doing the sync and then switching the system. There is pg_standby available for. Cheers, Frank signature.asc Description: OpenPGP digital signature
Re: [GENERAL] CPU move
This message has been digitally signed by the sender. Re___GENERAL__CPU_move.eml Description: Binary data - Hi-Tech Gears Ltd, Gurgaon, India -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] General performance/load issue
On 27 Listopad 2011, 10:45, Gaëtan Allart wrote: Actually, this is because I changed sort_mem to 4 Mb as asked by Robert. I removed this setting.. This is exactly the reason why it's recommended not to do any changes until it's reasonably certain what is the caause. Did increasing the work_mem again solved the issues? Is the database running fine? If no, post the iotop output again, so we can see what was the impact. And post the EXPLAIN ANALYZE of the query, so we can see if the estimates are OK. Anyway, Rober was right - the work_mem=128MB is rather large and should be decreased. Use something like a binary search to find the right value - use 64MB and watch the log for temp file messages. If there's a lot of messages, choose the upper interval and set (64+128)/2 = 96MB, otherwise 32MB. And so on. That should lead you to the minimal work_mem value. Tomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] text search synonym dictionary anomaly with numbers
Richard,
you should check your mapping - '1st' belongs to 'numword' and may be processed
in a different way than 'first' or '1'.
Oleg
On Sat, 26 Nov 2011, Richard Greenwood wrote:
I am working with street address data in which 'first st' has been
entered as '1 st' and so on. So I have created a text search
dictionary with entries:
first 1
1st 1
And initially it seems to be working properly:
SELECT ts_lexize('rwg_synonym','first');
ts_lexize
---
{1}
SELECT ts_lexize('rwg_synonym','1st');
ts_lexize
---
{1}
But my queries on '1st' are not returning the expected results:
SELECT count(*) FROM parcel_attrib WHERE txtsrch @@ to_tsquery('1');
count
---
403 - this is what I want
SELECT count(*) FROM parcel_attrib WHERE txtsrch @@ to_tsquery('first');
count
---
403 - this is also good
SELECT count(*) FROM parcel_attrib WHERE txtsrch @@ to_tsquery('1st');
count
---
4 - this is not good. There are 4 records that do have '1st',
but why am I not getting 403 records?
Thanks for reading,
Rich
Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: o...@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] text search synonym dictionary anomaly with numbers
Oleg,
Thank you. I am sure that you have identified my problem.
\dF+ english (output below) lists my dictionary which is named
'rwg_synonym' before numword so I would have thought that my
dictionary would have normalized '1st' to '1' before the numword
dictionary was reached. Maybe this question belongs in a new thread,
but I do thank you for helping me to look in the correct place.
Best regards,
Rich
fremontwy=# \dF+ english
Text search configuration pg_catalog.english
Parser: pg_catalog.default
Token | Dictionaries
-+--
asciihword | english_stem
asciiword | rwg_synonym,english_stem
email | simple
file| simple
float | simple
host| simple
hword | english_stem
hword_asciipart | english_stem
hword_numpart | simple
hword_part | english_stem
int | simple
numhword| simple
numword | simple
sfloat | simple
uint| simple
url | simple
url_path| simple
version | simple
word| english_stem
On Sun, Nov 27, 2011 at 7:29 AM, Oleg Bartunov o...@sai.msu.su wrote:
Richard,
you should check your mapping - '1st' belongs to 'numword' and may be
processed
in a different way than 'first' or '1'.
Oleg
On Sat, 26 Nov 2011, Richard Greenwood wrote:
I am working with street address data in which 'first st' has been
entered as '1 st' and so on. So I have created a text search
dictionary with entries:
first 1
1st 1
And initially it seems to be working properly:
SELECT ts_lexize('rwg_synonym','first');
ts_lexize
---
{1}
SELECT ts_lexize('rwg_synonym','1st');
ts_lexize
---
{1}
But my queries on '1st' are not returning the expected results:
SELECT count(*) FROM parcel_attrib WHERE txtsrch @@ to_tsquery('1');
count
---
403 - this is what I want
SELECT count(*) FROM parcel_attrib WHERE txtsrch @@ to_tsquery('first');
count
---
403 - this is also good
SELECT count(*) FROM parcel_attrib WHERE txtsrch @@ to_tsquery('1st');
count
---
4 - this is not good. There are 4 records that do have '1st',
but why am I not getting 403 records?
Thanks for reading,
Rich
Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: o...@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
--
Richard Greenwood
richard.greenw...@gmail.com
www.greenwoodmap.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PostgreSQL poster
I was looking for some PostgreSQL promotional material and found this: http://imgur.com/4VUUw I would very much like to get a high-res version of this image - does anyone here have it? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] text search synonym dictionary anomaly with numbers
To answer my own question - my synonym dictionary was not be applied
to '1st' because '1st' is a numword, not an asciiword, and my synonym
dictionary was not mapped to numword. To map a dictionary token class:
ALTER TEXT SEARCH CONFIGURATION english
ALTER MAPPING FOR numword WITH my_synonym_dictionary, simple;
The dictionary must already have been created with CREATE TEXT SEARCH
DICTIONARY
Rich
On Sun, Nov 27, 2011 at 9:57 AM, Richard Greenwood
richard.greenw...@gmail.com wrote:
Oleg,
Thank you. I am sure that you have identified my problem.
\dF+ english (output below) lists my dictionary which is named
'rwg_synonym' before numword so I would have thought that my
dictionary would have normalized '1st' to '1' before the numword
dictionary was reached. Maybe this question belongs in a new thread,
but I do thank you for helping me to look in the correct place.
Best regards,
Rich
fremontwy=# \dF+ english
Text search configuration pg_catalog.english
Parser: pg_catalog.default
Token | Dictionaries
-+--
asciihword | english_stem
asciiword | rwg_synonym,english_stem
email | simple
file | simple
float | simple
host | simple
hword | english_stem
hword_asciipart | english_stem
hword_numpart | simple
hword_part | english_stem
int | simple
numhword | simple
numword | simple
sfloat | simple
uint | simple
url | simple
url_path | simple
version | simple
word | english_stem
On Sun, Nov 27, 2011 at 7:29 AM, Oleg Bartunov o...@sai.msu.su wrote:
Richard,
you should check your mapping - '1st' belongs to 'numword' and may be
processed
in a different way than 'first' or '1'.
Oleg
On Sat, 26 Nov 2011, Richard Greenwood wrote:
I am working with street address data in which 'first st' has been
entered as '1 st' and so on. So I have created a text search
dictionary with entries:
first 1
1st 1
And initially it seems to be working properly:
SELECT ts_lexize('rwg_synonym','first');
ts_lexize
---
{1}
SELECT ts_lexize('rwg_synonym','1st');
ts_lexize
---
{1}
But my queries on '1st' are not returning the expected results:
SELECT count(*) FROM parcel_attrib WHERE txtsrch @@ to_tsquery('1');
count
---
403 - this is what I want
SELECT count(*) FROM parcel_attrib WHERE txtsrch @@ to_tsquery('first');
count
---
403 - this is also good
SELECT count(*) FROM parcel_attrib WHERE txtsrch @@ to_tsquery('1st');
count
---
4 - this is not good. There are 4 records that do have '1st',
but why am I not getting 403 records?
Thanks for reading,
Rich
Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: o...@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
--
Richard Greenwood
richard.greenw...@gmail.com
www.greenwoodmap.com
--
Richard Greenwood
richard.greenw...@gmail.com
www.greenwoodmap.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Way to create unique constraint in Postgres even with null columns
I have a table with this layout: CREATE TABLE Favorites ( FavoriteId uuid NOT NULL, --Primary key UserId uuid NOT NULL, RecipeId uuid NOT NULL, MenuId uuid ) I want to create a unique constraint similar to this: ALTER TABLE Favorites ADD CONSTRAINT Favorites_UniqueFavorite UNIQUE(UserId, MenuId, RecipeId); However, this will allow multiple rows with the same UserId and RecipeId, if the MenuId is null. I want to allow a NULL MenuId to store a favorite that has no associated menu, but I only want at most one of these rows per user/recipe pair. The ideas I have so far are: - 1) Use some hard-coded UUID (such as all zeros) instead of null. However, MenuId has a FK constraint on each user's menus, so I'd then have to create a special null menu for every user which is a hassle. - 2) Check for existence of an existing null entry using a trigger instead. I think this is a hassle and I like avoiding triggers wherever possible. Plus, I don't trust them to guarantee my data is never in a bad state. - 3) Just forget about it and check for the previous existence of a null entry in the middle-ware or a insert function, and don't have this constraint. Is there any method I'm forgetting? I'm using Postgres 9.0. Thanks! -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Way to create unique constraint in Postgres even with null columns
Hello 2011/11/27 Mike Christensen m...@kitchenpc.com: I have a table with this layout: CREATE TABLE Favorites ( FavoriteId uuid NOT NULL, --Primary key UserId uuid NOT NULL, RecipeId uuid NOT NULL, MenuId uuid ) I want to create a unique constraint similar to this: ALTER TABLE Favorites ADD CONSTRAINT Favorites_UniqueFavorite UNIQUE(UserId, MenuId, RecipeId); just idea add index CREATE UNIQUE INDEX foo_idx ON Favorites(UserId, Recipiend) WHERE MenuId IS NULL Regards Pavel Stehule However, this will allow multiple rows with the same UserId and RecipeId, if the MenuId is null. I want to allow a NULL MenuId to store a favorite that has no associated menu, but I only want at most one of these rows per user/recipe pair. The ideas I have so far are: - 1) Use some hard-coded UUID (such as all zeros) instead of null. However, MenuId has a FK constraint on each user's menus, so I'd then have to create a special null menu for every user which is a hassle. - 2) Check for existence of an existing null entry using a trigger instead. I think this is a hassle and I like avoiding triggers wherever possible. Plus, I don't trust them to guarantee my data is never in a bad state. - 3) Just forget about it and check for the previous existence of a null entry in the middle-ware or a insert function, and don't have this constraint. Is there any method I'm forgetting? I'm using Postgres 9.0. Thanks! -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Way to create unique constraint in Postgres even with null columns
Mike Christensen wrote on 27.11.2011 22:18: I have a table with this layout: CREATE TABLE Favorites ( FavoriteId uuid NOT NULL, --Primary key UserId uuid NOT NULL, RecipeId uuid NOT NULL, MenuId uuid ) I want to create a unique constraint similar to this: ALTER TABLE Favorites ADD CONSTRAINT Favorites_UniqueFavorite UNIQUE(UserId, MenuId, RecipeId); However, this will allow multiple rows with the same UserId and RecipeId, if the MenuId is null. I want to allow a NULL MenuId to store a favorite that has no associated menu, but I only want at most one of these rows per user/recipe pair. In addition to the above unique constraint you will need another one: CREATE UNIQUE INDEX Favorites_UniqueFavorite ON (UserId, MenuId) WHERE RecipeId IS NULL; -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Way to create unique constraint in Postgres even with null columns
On Sun, Nov 27, 2011 at 1:47 PM, Thomas Kellerer spam_ea...@gmx.net wrote: Mike Christensen wrote on 27.11.2011 22:18: I have a table with this layout: CREATE TABLE Favorites ( FavoriteId uuid NOT NULL, --Primary key UserId uuid NOT NULL, RecipeId uuid NOT NULL, MenuId uuid ) I want to create a unique constraint similar to this: ALTER TABLE Favorites ADD CONSTRAINT Favorites_UniqueFavorite UNIQUE(UserId, MenuId, RecipeId); However, this will allow multiple rows with the same UserId and RecipeId, if the MenuId is null. I want to allow a NULL MenuId to store a favorite that has no associated menu, but I only want at most one of these rows per user/recipe pair. In addition to the above unique constraint you will need another one: CREATE UNIQUE INDEX Favorites_UniqueFavorite ON (UserId, MenuId) WHERE RecipeId IS NULL; Excellent solution! Thanks all.. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Way to create unique constraint in Postgres even with null columns
-Original Message- From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Mike Christensen Sent: Sunday, November 27, 2011 5:02 PM To: Thomas Kellerer Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] Way to create unique constraint in Postgres even with null columns On Sun, Nov 27, 2011 at 1:47 PM, Thomas Kellerer spam_ea...@gmx.net wrote: Mike Christensen wrote on 27.11.2011 22:18: I have a table with this layout: CREATE TABLE Favorites ( FavoriteId uuid NOT NULL, --Primary key UserId uuid NOT NULL, RecipeId uuid NOT NULL, MenuId uuid ) I want to create a unique constraint similar to this: ALTER TABLE Favorites ADD CONSTRAINT Favorites_UniqueFavorite UNIQUE(UserId, MenuId, RecipeId); However, this will allow multiple rows with the same UserId and RecipeId, if the MenuId is null. I want to allow a NULL MenuId to store a favorite that has no associated menu, but I only want at most one of these rows per user/recipe pair. In addition to the above unique constraint you will need another one: CREATE UNIQUE INDEX Favorites_UniqueFavorite ON (UserId, MenuId) WHERE RecipeId IS NULL; Excellent solution! Thanks all.. - While the conditional index will work this is one of many situations where being explicit is probably the better option. It is quite likely that you will want to use the MenuID in queries and having to deal with NULL in those situations is messy. You should create a DEFAULT menu for each user and replace any existing NULLs with the DEFAULT MenuID for the given user. Then, make the MenuID column NOT NULL. Also, the index example above presumes you want RecipeId to be Null-able as opposed to MenuId as described in your original post. David J. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Way to create unique constraint in Postgres even with null columns
On Sun, Nov 27, 2011 at 2:18 PM, David Johnston pol...@yahoo.com wrote: -Original Message- From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Mike Christensen Sent: Sunday, November 27, 2011 5:02 PM To: Thomas Kellerer Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] Way to create unique constraint in Postgres even with null columns On Sun, Nov 27, 2011 at 1:47 PM, Thomas Kellerer spam_ea...@gmx.net wrote: Mike Christensen wrote on 27.11.2011 22:18: I have a table with this layout: CREATE TABLE Favorites ( FavoriteId uuid NOT NULL, --Primary key UserId uuid NOT NULL, RecipeId uuid NOT NULL, MenuId uuid ) I want to create a unique constraint similar to this: ALTER TABLE Favorites ADD CONSTRAINT Favorites_UniqueFavorite UNIQUE(UserId, MenuId, RecipeId); However, this will allow multiple rows with the same UserId and RecipeId, if the MenuId is null. I want to allow a NULL MenuId to store a favorite that has no associated menu, but I only want at most one of these rows per user/recipe pair. In addition to the above unique constraint you will need another one: CREATE UNIQUE INDEX Favorites_UniqueFavorite ON (UserId, MenuId) WHERE RecipeId IS NULL; Excellent solution! Thanks all.. - While the conditional index will work this is one of many situations where being explicit is probably the better option. It is quite likely that you will want to use the MenuID in queries and having to deal with NULL in those situations is messy. You should create a DEFAULT menu for each user and replace any existing NULLs with the DEFAULT MenuID for the given user. Then, make the MenuID column NOT NULL. Also, the index example above presumes you want RecipeId to be Null-able as opposed to MenuId as described in your original post. Yea I assumed the idea was to do something like: CREATE UNIQUE INDEX IDX_Favorites_NullMenu ON Favorites(UserId, RecipeId) WHERE MenuId IS NULL; CREATE UNIQUE INDEX IDX_Favorites_UniqueMenu ON Favorites(UserId, RecipeId, MenuId) WHERE MenuId IS NOT NULL; I'm not sure what situations become messy when MenuId allows NULLs though. Maybe you can provide a few more details? I do agree creating a default Menu for each user is the way to go. However, it makes inserting a lot more difficult. If a user adds a recipe to their favorites, and does not specify a menu, I then have to go lookup the UUID for their default menu first. It's not a huge deal, but I'd like to avoid that if possible. I think NULL makes sense here since it really does mean there is no menu for this row. Thanks! Mike -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Way to create unique constraint in Postgres even with null columns
David Johnston wrote on 27.11.2011 23:18: Also, the index example above presumes you want RecipeId to be Null-able as opposed to MenuId as described in your original post. Well of course that was a typo in my answer, it should have been: CREATE UNIQUE INDEX Favorites_UniqueFavorite ON (UserId, RecipeId) WHERE MenuId IS NULL; -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Way to create unique constraint in Postgres even with null columns
On Nov 27, 2011, at 17:43, Mike Christensen m...@kitchenpc.com wrote: On Sun, Nov 27, 2011 at 2:18 PM, David Johnston pol...@yahoo.com wrote: -Original Message- From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Mike Christensen Sent: Sunday, November 27, 2011 5:02 PM To: Thomas Kellerer Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] Way to create unique constraint in Postgres even with null columns On Sun, Nov 27, 2011 at 1:47 PM, Thomas Kellerer spam_ea...@gmx.net wrote: Mike Christensen wrote on 27.11.2011 22:18: I have a table with this layout: CREATE TABLE Favorites ( FavoriteId uuid NOT NULL, --Primary key UserId uuid NOT NULL, RecipeId uuid NOT NULL, MenuId uuid ) I want to create a unique constraint similar to this: ALTER TABLE Favorites ADD CONSTRAINT Favorites_UniqueFavorite UNIQUE(UserId, MenuId, RecipeId); However, this will allow multiple rows with the same UserId and RecipeId, if the MenuId is null. I want to allow a NULL MenuId to store a favorite that has no associated menu, but I only want at most one of these rows per user/recipe pair. In addition to the above unique constraint you will need another one: CREATE UNIQUE INDEX Favorites_UniqueFavorite ON (UserId, MenuId) WHERE RecipeId IS NULL; Excellent solution! Thanks all.. - While the conditional index will work this is one of many situations where being explicit is probably the better option. It is quite likely that you will want to use the MenuID in queries and having to deal with NULL in those situations is messy. You should create a DEFAULT menu for each user and replace any existing NULLs with the DEFAULT MenuID for the given user. Then, make the MenuID column NOT NULL. Also, the index example above presumes you want RecipeId to be Null-able as opposed to MenuId as described in your original post. Yea I assumed the idea was to do something like: CREATE UNIQUE INDEX IDX_Favorites_NullMenu ON Favorites(UserId, RecipeId) WHERE MenuId IS NULL; CREATE UNIQUE INDEX IDX_Favorites_UniqueMenu ON Favorites(UserId, RecipeId, MenuId) WHERE MenuId IS NOT NULL; I'm not sure what situations become messy when MenuId allows NULLs though. Maybe you can provide a few more details? I do agree creating a default Menu for each user is the way to go. However, it makes inserting a lot more difficult. If a user adds a recipe to their favorites, and does not specify a menu, I then have to go lookup the UUID for their default menu first. It's not a huge deal, but I'd like to avoid that if possible. I think NULL makes sense here since it really does mean there is no menu for this row. Thanks! Mike You agree it is the right thing to do but claim doing so is difficult while then immediately stating that creating and looking up the default uuid is not a huge deal... Any query using this table's menuid is going to be suspect since it can be null. Since you could be linking the Menu table to it any menu oriented query is now suspect. Aggregate queries using this column are as well. Dealing with two where clauses (one with the IS NULL construct and one without) introduces uncertainty as well. You are introducing a state of a user's recipe as being on or off menu when it is a much simpler model to just say every user recipe must be on at least one menu. Period. Achieving that simplicity is not difficult and so, for me at least, I'd need convincing as to why not to do it. David J. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] reading build config.log -- possible bug?
Looking to see where my new data directory is in recently built 9.1 I
happened upon what could potentially be a bug in configure:
Just after the line which begins configure_args= (line 11068 for me,
99% of buffer) I find:
datadir='${datarootdir}'
datarootdir='${prefix}/share'
I'm troubled that datadir may be getting set too early since that's the
first mention of either variable in config.log? I don't see 'datadir'
anywhere else in the file but that's not abnormal.
Paranoid but maybe they _are_ after me,
rjs
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] reading build config.log -- possible bug?
Rob Sargentg robjsarg...@gmail.com writes:
Looking to see where my new data directory is in recently built 9.1 I
happened upon what could potentially be a bug in configure:
Just after the line which begins configure_args= (line 11068 for me,
99% of buffer) I find:
datadir='${datarootdir}'
datarootdir='${prefix}/share'
I'm troubled that datadir may be getting set too early since that's the
first mention of either variable in config.log? I don't see 'datadir'
anywhere else in the file but that's not abnormal.
I think you're reading the alphabetized dump of variables' final values,
no?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] reading build config.log -- possible bug?
On 11/27/2011 09:31 PM, Tom Lane wrote:
Rob Sargentgrobjsarg...@gmail.com writes:
Looking to see where my new data directory is in recently built 9.1 I
happened upon what could potentially be a bug in configure:
Just after the line which begins configure_args= (line 11068 for me,
99% of buffer) I find:
datadir='${datarootdir}'
datarootdir='${prefix}/share'
I'm troubled that datadir may be getting set too early since that's the
first mention of either variable in config.log? I don't see 'datadir'
anywhere else in the file but that's not abnormal.
I think you're reading the alphabetized dump of variables' final values,
no?
regards, tom lane
Ah, yes... Note to self: Step back, see the larger picture...
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
