Re: [HACKERS] TODO request: log_long_transaction
On 11/7/14, 1:19 PM, Michael Banck wrote: Am Montag, den 27.10.2014, 19:29 + schrieb Thom Brown: On 27 October 2014 19:21, Josh Berkusj...@agliodbs.com wrote: I just realized that there is one thing we can't log currently: transactions which last more than #ms. This is valuable diagnostic information when looking for issues like causes of bloat and deadlocks. I'd like it to be on the TODO list because it seems like part of a good GSOC project or first-time contribution. So effectively, log_min_duration_transaction? Sounds useful. FWIW, I've also wanted the equivalent of statement_timeout for transactions; the ability to abort a transaction if it runs for too long. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO request: log_long_transaction
Robert Haas robertmh...@gmail.com wrote: 3. Should long transactions which are rolled back be logged as well? Yes. +1 4. We log the statement when exceeding log_min_duration_statement, but for transactions, that does not make a lot of sense, or should the last statement be logged? I don't think that would be particularly useful. This is a potentially serious problem with this whole idea, and the idea in #2. You can log that it happened, but without some idea of what it did, it's probably not going to be too useful. The database currently lacks two things which I have seen used for this purpose in database access middleware: an application area (sort of like application name, but more fine-grained and expected to change within the lifetime of a connection) and a transaction class name. For a connection related to an In Court application, there might be an application area of Mass Traffic Dispo which has 10 or 20 transaction classes. Examples of transaction classes could be to enter a Default Judgment of Guilty (for all cases scheduled for that session where the defendant didn't appear), or to Grant Time to Pay to those found guilty who have not paid the citation in full. (It could often make sense for a given transaction class to be usable from more than one application area, and for the context to be valuable.) If we added GUCs for application area and transaction class, those could be included in the log message for a long-running transaction. That would make the messages useful -- at least for occurrences when either or both were set. The question is whether people would be willing to set these GUCs to make the logging useful -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO request: log_long_transaction
Hi,
Am Montag, den 27.10.2014, 19:29 + schrieb Thom Brown:
On 27 October 2014 19:21, Josh Berkus j...@agliodbs.com wrote:
I just realized that there is one thing we can't log currently:
transactions which last more than #ms. This is valuable diagnostic
information when looking for issues like causes of bloat and deadlocks.
I'd like it to be on the TODO list because it seems like part of a good
GSOC project or first-time contribution.
So effectively, log_min_duration_transaction? Sounds useful.
Questions are:
1. Should this log when the duration is exceeded (like log_lock_waits),
or on commit? I guess the latter, cause log_lock_waits is kinda an
offshoot from the deadlock detector, and other things don't work in a
similar fashion and/or this might be quite tricky and a non-starter.
2. It would be quite nice to log long-running idle-in-transaction (i.e.
transactions which have been idle for a long time, not necessarily long
transactions which are idle every now and then), but see 1.
3. Should long transactions which are rolled back be logged as well?
4. We log the statement when exceeding log_min_duration_statement, but
for transactions, that does not make a lot of sense, or should the last
statement be logged? I don't think that would be particularly useful.
So if you just want to log transactions which took longer than
log_min_duration_transaction on commit (but not rollback), that's rather
easy and I've attached a PoC patch against master for that.
I took the logic from check_log_duration(), so it is pretty trivial. In
general, one could argue that tcop/postgres.c might be the better place,
and check_log_duration() should be refactored to support both
log_min_duration_statement and log_min_duration_transaction, but (i) I
decided to include the xid in the log message to have at least some
information (even though that might duplicate information in
log_line_prefix) which I don't think is easily accesible from tcop and
(ii) when I hooked it into finish_xact_command(), it did not work well,
e.g. it logged on psql statements like \d.
Thoughts?
Michael
--
Michael Banck
Projektleiter / Berater
Tel.: +49 (2161) 4643-171
Fax: +49 (2161) 4643-100
Email: michael.ba...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index 6f92bad..da08c46 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xact.c
@@ -794,6 +794,46 @@ TransactionStartedDuringRecovery(void)
}
/*
+ * CheckCurrentTransactionDuration
+ *
+ * Returns true if the current transaction's duration is longer than
+ * log_min_duration_transaction.
+ */
+bool
+CheckCurrentTransactionDuration(char *msec_str)
+{
+ long secs;
+ int usecs;
+ int msecs;
+ bool exceeded;
+
+ TimestampDifference(xactStartTimestamp,
+ xactStopTimestamp,
+ secs,
+ usecs);
+ msecs = usecs / 1000;
+
+ /*
+ * This odd-looking test for log_min_duration_transaction being exceeded
+ * is designed to avoid integer overflow with very long durations:
+ * don't compute secs * 1000 until we've verified it will fit in int.
+ */
+ exceeded = (log_min_duration_transaction == 0 ||
+(log_min_duration_transaction 0
+(secs log_min_duration_transaction / 1000 ||
+secs * 1000 + msecs = log_min_duration_transaction)));
+
+ if (exceeded)
+ {
+ snprintf(msec_str, 32, %ld.%03d,
+ secs * 1000 + msecs, usecs % 1000);
+ return true;
+ }
+ return false;
+}
+
+
+/*
* CommandCounterIncrement
*/
void
@@ -1007,6 +1047,7 @@ RecordTransactionCommit(void)
SharedInvalidationMessage *invalMessages = NULL;
bool RelcacheInitFileInval = false;
bool wrote_xlog;
+ char msec_str[32];
/* Get data needed for commit record */
nrels = smgrGetPendingDeletes(true, rels);
@@ -1235,6 +1276,12 @@ RecordTransactionCommit(void)
END_CRIT_SECTION();
}
+ /* Check whether to log the duration of the transaction */
+ if (CheckCurrentTransactionDuration(msec_str))
+ ereport(LOG,
+ (errmsg(transaction %u duration: %s ms, xid, msec_str),
+ errhidestmt(true)));
+
/* Compute latestXid while we have the child XIDs handy */
latestXid = TransactionIdLatest(xid, nchildren, children);
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index aca4243..6e8cc43 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -451,6 +451,7 @@ int log_min_error_statement = ERROR;
int log_min_messages = WARNING;
int client_min_messages = NOTICE;
int log_min_duration_statement = -1;
+int log_min_duration_transaction = -1;
int log_temp_files = -1;
int trace_recovery_messages = LOG;
@@ -2211,6 +2212,18 @@ static struct config_int ConfigureNamesInt[] =
},
{
+ {log_min_duration_transaction, PGC_SUSET, LOGGING_WHEN,
+
Re: [HACKERS] TODO request: log_long_transaction
You should add this patch here, so it doesn't get forgotten: https://commitfest.postgresql.org/action/commitfest_view/open On Fri, Nov 7, 2014 at 2:19 PM, Michael Banck michael.ba...@credativ.de wrote: 1. Should this log when the duration is exceeded (like log_lock_waits), or on commit? I guess the latter, cause log_lock_waits is kinda an offshoot from the deadlock detector, and other things don't work in a similar fashion and/or this might be quite tricky and a non-starter. Either could be useful. I'm guessing Josh had the latter in mind. 2. It would be quite nice to log long-running idle-in-transaction (i.e. transactions which have been idle for a long time, not necessarily long transactions which are idle every now and then), but see 1. I agree. You could implement this by setting a timeout when going idle in transaction. 3. Should long transactions which are rolled back be logged as well? Yes. 4. We log the statement when exceeding log_min_duration_statement, but for transactions, that does not make a lot of sense, or should the last statement be logged? I don't think that would be particularly useful. This is a potentially serious problem with this whole idea, and the idea in #2. You can log that it happened, but without some idea of what it did, it's probably not going to be too useful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] TODO request: log_long_transaction
Hackers, I just realized that there is one thing we can't log currently: transactions which last more than #ms. This is valuable diagnostic information when looking for issues like causes of bloat and deadlocks. I'd like it to be on the TODO list because it seems like part of a good GSOC project or first-time contribution. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO request: log_long_transaction
On 27 October 2014 19:21, Josh Berkus j...@agliodbs.com wrote: Hackers, I just realized that there is one thing we can't log currently: transactions which last more than #ms. This is valuable diagnostic information when looking for issues like causes of bloat and deadlocks. I'd like it to be on the TODO list because it seems like part of a good GSOC project or first-time contribution. So effectively, log_min_duration_transaction? Sounds useful. Thom
Re: [HACKERS] TODO request: multi-dimensional arrays in PL/pythonU
On Wed, Aug 14, 2013 at 9:34 PM, Peter Eisentraut pete...@gmx.net wrote: On Tue, 2013-08-13 at 14:30 -0700, Josh Berkus wrote: Currently PL/python has 1 dimension hardcoded for returning arrays: create or replace function nparr () returns float[][] language plpythonu as $f$ from numpy import array x = ((1.0,2.0),(3.0,4.0),(5.0,6.0),) return x $f$; There is no way to know how many dimensions the function expects to get back. (float[][] doesn't actually mean anything.) So when converting the return value back to SQL, you'd have to guess, is the first element convertible to float (how do you know?), if not, does it support the sequence protocol, if yes, so let's try to construct a multidimensional array. What if the first element is a float but the second is not? It would be useful to have a solution for that, but it would need to be more principled than what I just wrote. ndarray has a shape attribute. Perhaps they could be supported if they follow the ndarray-like protocol? (ie: have a shape attribute) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO request: multi-dimensional arrays in PL/pythonU
There is no way to know how many dimensions the function expects to get back. (float[][] doesn't actually mean anything.) So when converting the return value back to SQL, you'd have to guess, is the first element convertible to float (how do you know?), if not, does it support the sequence protocol, if yes, so let's try to construct a multidimensional array. What if the first element is a float but the second is not? It would be useful to have a solution for that, but it would need to be more principled than what I just wrote. Well, PL/R is able to return multi-dim arrays. So we have some code precedent for this. Mind you, there's fewer checks required for PL/R, because like Postgres it requires each dimension of the array to have identical length and all items to be the same type. Given that, it might be easier to support this first for numpy, which also has the same restrictions. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO request: multi-dimensional arrays in PL/pythonU
On Tue, 2013-08-13 at 14:30 -0700, Josh Berkus wrote: Currently PL/python has 1 dimension hardcoded for returning arrays: create or replace function nparr () returns float[][] language plpythonu as $f$ from numpy import array x = ((1.0,2.0),(3.0,4.0),(5.0,6.0),) return x $f$; There is no way to know how many dimensions the function expects to get back. (float[][] doesn't actually mean anything.) So when converting the return value back to SQL, you'd have to guess, is the first element convertible to float (how do you know?), if not, does it support the sequence protocol, if yes, so let's try to construct a multidimensional array. What if the first element is a float but the second is not? It would be useful to have a solution for that, but it would need to be more principled than what I just wrote. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] TODO request: multi-dimensional arrays in PL/pythonU
All, Currently PL/python has 1 dimension hardcoded for returning arrays: create or replace function nparr () returns float[][] language plpythonu as $f$ from numpy import array x = ((1.0,2.0),(3.0,4.0),(5.0,6.0),) return x $f$; josh=# select nparr() ; ERROR: invalid input syntax for type double precision: (1.0, 2.0) CONTEXT: while creating return value PL/Python function nparr josh=# I'd like to add the following TODO to the TODO list: PL/Python [] Allow functions to return multi-dimensional arrays from lists or numpy arrays. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO Request
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hannu Krosing Ühel kenal päeval, T, 2006-08-29 kell 22:12, kirjutas Joshua D. Drake: Auto creations of partitions This would be something like: create table foo () partition by ... from the referenced MySQL manual entry CREATE TABLE members ( ... joined DATE NOT NULL ) PARTITION BY KEY(joined) PARTITIONS 6; Do you have any idea how this should work ? What date range should go into which partition ? Since we don't have any knowledge about the date ranges in question, and the fact that they could change over time, I think the only stable way to handle this scenario would be to use a hash function which had 6 buckets (something like 'date % 6' could work). I do see an issue, if someone wanted to change the number of partitions in use, since it would have to rehash the table, and move data around. I don't see any other way to handle this, but I might not be thinking hard enough. -rocco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] TODO Request
Rocco Altier wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hannu Krosing Ühel kenal päeval, T, 2006-08-29 kell 22:12, kirjutas Joshua D. Drake: Auto creations of partitions This would be something like: create table foo () partition by ... from the referenced MySQL manual entry CREATE TABLE members ( ... joined DATE NOT NULL ) PARTITION BY KEY(joined) PARTITIONS 6; Do you have any idea how this should work ? What date range should go into which partition ? Since we don't have any knowledge about the date ranges in question, and the fact that they could change over time, I think the only stable way to handle this scenario would be to use a hash function which had 6 buckets (something like 'date % 6' could work). IMHO we shouldn't be giving too many partitioning options until we solve the important problems it brings with it, like FKs or unique constraints not working across the hierarchy. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO Request
Ühel kenal päeval, T, 2006-08-29 kell 22:12, kirjutas Joshua D. Drake: Auto creations of partitions This would be something like: create table foo () partition by ... from the referenced MySQL manual entry CREATE TABLE members ( ... joined DATE NOT NULL ) PARTITION BY KEY(joined) PARTITIONS 6; Do you have any idea how this should work ? What date range should go into which partition ? For reference I am directly apply my fair use rights to the above per the MySQL development docs. Reference below: http://dev.mysql.com/doc/refman/5.1/en/partitioning.html Yes I am fully aware that we don't need to do something just because MySQL does it. However, Oracle has similar functionality and I would like to see us keep up :) Of course I would like it to be done correctly :) Do you know if ther is anything about partitioning in any ISO/ANSI SQL standards ? -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TODO Request
Added to TODO: * Simplify ability to create partitioned tables This would allow creation of partitioned tables without requiring creation of rules for INSERT/UPDATE/DELETE, and constraints for rapid partition selection. Options could include range and hash partition selection. * Allow auto-selection of partitioned tables for min/max() operations I didn't add subparitions because that seems pretty complicated. --- Joshua D. Drake wrote: Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Can we get: Well this should be fun. Multiple table indexes (for uniqueness across partitions for example) Auto creations of partitions This would be something like: create table foo () partition by ... Hash partitioning Partitioning by HASH is used primarily to ensure an even distribution of data among a predetermined number of partitions. Key partitioning Partitioning by key is similar to partitioning by hash, except that where hash partitioning employs a user-defined expression. Sub partitioning Subpartitioning ? also known as composite partitioning ? is the further division of each partition in a partitioned table. (partitions that have partitions) Added to the TODO list? Perhaps a certain amount of specificity as to what these mean, and why we need them, would be appropriate. For reference I am directly apply my fair use rights to the above per the MySQL development docs. Reference below: http://dev.mysql.com/doc/refman/5.1/en/partitioning.html Yes I am fully aware that we don't need to do something just because MySQL does it. However, Oracle has similar functionality and I would like to see us keep up :) Of course I would like it to be done correctly :) Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO Request
Bruce Momjian wrote: Added to TODO: * Simplify ability to create partitioned tables This would allow creation of partitioned tables without requiring creation of rules for INSERT/UPDATE/DELETE, and constraints for rapid partition selection. Options could include range and hash partition selection. * Allow auto-selection of partitioned tables for min/max() operations I didn't add subparitions because that seems pretty complicated. Thanks for this. What about the other partioning types? And complicated should be what we are after :) Sincerely, Joshua D. Drake --- Joshua D. Drake wrote: Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Can we get: Well this should be fun. Multiple table indexes (for uniqueness across partitions for example) Auto creations of partitions This would be something like: create table foo () partition by ... Hash partitioning Partitioning by HASH is used primarily to ensure an even distribution of data among a predetermined number of partitions. Key partitioning Partitioning by key is similar to partitioning by hash, except that where hash partitioning employs a user-defined expression. Sub partitioning Subpartitioning ? also known as composite partitioning ? is the further division of each partition in a partitioned table. (partitions that have partitions) Added to the TODO list? Perhaps a certain amount of specificity as to what these mean, and why we need them, would be appropriate. For reference I am directly apply my fair use rights to the above per the MySQL development docs. Reference below: http://dev.mysql.com/doc/refman/5.1/en/partitioning.html Yes I am fully aware that we don't need to do something just because MySQL does it. However, Oracle has similar functionality and I would like to see us keep up :) Of course I would like it to be done correctly :) Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] TODO Request
Joshua D. Drake wrote: Bruce Momjian wrote: Added to TODO: * Simplify ability to create partitioned tables This would allow creation of partitioned tables without requiring creation of rules for INSERT/UPDATE/DELETE, and constraints for rapid partition selection. Options could include range and hash partition selection. * Allow auto-selection of partitioned tables for min/max() operations I didn't add subparitions because that seems pretty complicated. Thanks for this. What about the other partioning types? And complicated should be what we Uh, what other types? I see key, hash, and sub listed below. are after :) It is not clear a complex solution would be accepted by the community. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] TODO Request
Bruce Momjian wrote: Joshua D. Drake wrote: Bruce Momjian wrote: Added to TODO: * Simplify ability to create partitioned tables This would allow creation of partitioned tables without requiring creation of rules for INSERT/UPDATE/DELETE, and constraints for rapid partition selection. Options could include range and hash partition selection. * Allow auto-selection of partitioned tables for min/max() operations I didn't add subparitions because that seems pretty complicated. Thanks for this. What about the other partioning types? And complicated should be what we Uh, what other types? I see key, hash, and sub listed below. Yeah, but I don't see them listed in the TODO... were you being implicit? Joshua D. Drake are after :) It is not clear a complex solution would be accepted by the community. -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO Request
On Tue, Aug 29, 2006 at 03:53:57PM -0700, Joshua D. Drake wrote: Hello, Can we get: Multiple table indexes (for uniqueness across partitions for example) Before any of the below happen, I think it'd be good to get a cleaner way to define partitions; one that didn't involve manually messing with constraints, etc. Auto creations of partitions That would be nice, though if we had a built-in job facility of some kind it wouldn't be needed for time-based partitioning. Hash partitioning Key partitioning Sub partitioning Is there anything stopping those from being done right now? The only thing I can think of that we're missing is an optimization where a partition with a single key doesn't contain that key's data. Currently, this can be done with UNION VIEW partitioning, but perhaps there's some more clever way to do it in the inheritance case. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] TODO Request
Hello, Can we get: Multiple table indexes (for uniqueness across partitions for example) Auto creations of partitions Hash partitioning Key partitioning Sub partitioning Added to the TODO list? Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] TODO Request
Joshua D. Drake [EMAIL PROTECTED] writes: Can we get: Multiple table indexes (for uniqueness across partitions for example) Auto creations of partitions Hash partitioning Key partitioning Sub partitioning Added to the TODO list? Perhaps a certain amount of specificity as to what these mean, and why we need them, would be appropriate. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] TODO Request
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Can we get: Well this should be fun. Multiple table indexes (for uniqueness across partitions for example) Auto creations of partitions This would be something like: create table foo () partition by ... Hash partitioning Partitioning by HASH is used primarily to ensure an even distribution of data among a predetermined number of partitions. Key partitioning Partitioning by key is similar to partitioning by hash, except that where hash partitioning employs a user-defined expression. Sub partitioning Subpartitioning — also known as composite partitioning — is the further division of each partition in a partitioned table. (partitions that have partitions) Added to the TODO list? Perhaps a certain amount of specificity as to what these mean, and why we need them, would be appropriate. For reference I am directly apply my fair use rights to the above per the MySQL development docs. Reference below: http://dev.mysql.com/doc/refman/5.1/en/partitioning.html Yes I am fully aware that we don't need to do something just because MySQL does it. However, Oracle has similar functionality and I would like to see us keep up :) Of course I would like it to be done correctly :) Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] TODO Request
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Can we get: Multiple table indexes (for uniqueness across partitions for example) Auto creations of partitions Hash partitioning Key partitioning Sub partitioning Added to the TODO list? Perhaps a certain amount of specificity as to what these mean, and why we need them, would be appropriate. Further on this is an additional reference: http://www.psoug.org/reference/partitions.html We should also probably add: Allow planner to correctly use indexes on min/max across partitions Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
