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 Berkus wrote:
> >I just realized that there is one thing we can't log currently:
> >transactions which last more than #ms. This is valuable diagnostic
> >inform
Robert Haas 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
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 wrote:
> 1. Should this log when the duration is exceeded (like log_lock_waits),
> or on commit? I guess the latter, cause log_
Hi,
Am Montag, den 27.10.2014, 19:29 + schrieb Thom Brown:
> On 27 October 2014 19:21, Josh Berkus 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 ca
On 27 October 2014 19:21, Josh Berkus 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
> 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
> sequ
On Wed, Aug 14, 2013 at 9:34 PM, Peter Eisentraut 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 impor
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$;
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 ()
> 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 refere
Ü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(j
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
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 pa
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 i
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
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 mes
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
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
"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 wha
19 matches
Mail list logo
