On Tue, Jun 21, 2016 at 2:02 PM, Dharini wrote:
> Background process is initialized at server start and when trying to run the
> tests i get the following error.
>
> $ make installcheck
> (using postmaster on Unix socket, default port)
> == dropping database "contrib_regression" ==
> On 19 Jun 2016, at 10:58, Tim Smith wrote:
>
> Hi,
>
> My postgresql-fu is not good enough to write a query to achieve this
> (some may well say r is a better suited tool to achieve this !).
>
> I need to calculate what I would call a correlation window on a time
> series of data, my table l
Hello,
very interesting comments and contributions, thank you.
>I've just tested pg_bulkload with the default settings, and it
>definitely isn't using the fsm to re-use freed space in the table. If
>they use WRITER = BUFFERED it would, though.
So with WRITER = BUFFERED it should be slower but fr
On Thu, Jun 16, 2016 at 1:46 PM, Martín Marqués wrote:
> The comment is accurate on what is going to be dumpable and what's not
> from the code. In our case, as the pgq schema is not dumpable becaause
> it comes from an extension, other objects it contain will not be
> dumpable as well.
>
> That's
2016-06-21 13:08 GMT-03:00 Robert Haas :
> On Thu, Jun 16, 2016 at 1:46 PM, Martín Marqués
> wrote:
>> The comment is accurate on what is going to be dumpable and what's not
>> from the code. In our case, as the pgq schema is not dumpable becaause
>> it comes from an extension, other objects it c
Thank you David.
-Allan.
On Mon, Jun 20, 2016 at 11:19 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Sun, Jun 19, 2016 at 5:09 PM, Allan Kamau wrote:
>
>> I have an xml document from which I would like to extract the contents of
>> several elements.
>>
>> I would like to use x
i'm cleaning up some queries for performance, and noticed that we never use
precision beyond the second (ie, `timestamp(0)`) in our business logic.
would there be any savings in storage or performance improvements from losing
the resolution on fractional seconds, or are `timestamp(precision)` ef
On 21/06/16 22:39, Jonathan Vanasco wrote:
> i'm cleaning up some queries for performance, and noticed that we never use
> precision beyond the second (ie, `timestamp(0)`) in our business logic.
>
> would there be any savings in storage or performance improvements from losing
> the resolution on
Jonathan Vanasco writes:
> would there be any savings in storage or performance improvements from losing
> the resolution on fractional seconds,
Storage-wise, no. If you have a resolution spec on your columns now,
I think dropping the resolution spec would save you a few nanoseconds per
row ins
On Jun 21, 2016, at 4:50 PM, Tom Lane wrote:
> Storage-wise, no. If you have a resolution spec on your columns now,
> I think dropping the resolution spec would save you a few nanoseconds per
> row insertion due to not having to apply the roundoff function. Adding
> one would certainly not impr
I have a handful of queries in the following general form that I can't seem to
optimize any further (same results on 9.3, 9.4, 9.5)
I'm wondering if anyone might have a suggestion, or if they're done.
The relevant table structure:
t_a2b
a_id INT references t_a(id)
On 06/21/2016 03:33 PM, Jonathan Vanasco wrote:
I have a handful of queries in the following general form that I can't seem to
optimize any further (same results on 9.3, 9.4, 9.5)
I'm wondering if anyone might have a suggestion, or if they're done.
The relevant table structure:
t_a2b
On Tue, Jun 21, 2016 at 6:44 PM, Adrian Klaver
wrote:
> On 06/21/2016 03:33 PM, Jonathan Vanasco wrote:
>
>>
>>
>> In effort of simplifying the work, I've created indexes on t_a that have
>> all the related columns.
>>
>> CREATE INDEX test_idx ON t_a(col_1, id) WHERE col_2 IS NOT FALSE;
>
Thanks for that, looks like something to sink my teeth into !
On 21 June 2016 at 13:29, Alban Hertroys wrote:
>
>> On 19 Jun 2016, at 10:58, Tim Smith wrote:
>>
>> Hi,
>>
>> My postgresql-fu is not good enough to write a query to achieve this
>> (some may well say r is a better suited tool to ac
On Jun 21, 2016, at 6:55 PM, David G. Johnston wrote:
> Aside from the name these indexes are identical...
sorry. tired eyes copy/pasting between windows and trying to 'average' out 40
similar queries.
> These two items combined reduce the desirability of diagnosing this...it
> doesn't see
15 matches
Mail list logo
