Hi
2017-05-22 22:21 GMT+02:00 Clemens Eisserer :
> Hi,
>
> I have a letancy-sensitive legacy application, where the time consumed
> by query planning was always causing some headaches.
> Currently it is running on postgresql-8.4 - will postgresql-10 support
> generating plans using multiple CPU c
On 23/05/17 08:21, Clemens Eisserer wrote:
> Hi,
>
> I have a letancy-sensitive legacy application, where the time consumed
> by query planning was always causing some headaches.
> Currently it is running on postgresql-8.4 - will postgresql-10 support
> generating plans using multiple CPU cores to
On Monday, May 22, 2017, Clemens Eisserer wrote:
> Hi,
>
> I have a letancy-sensitive legacy application, where the time consumed
> by query planning was always causing some headaches.
> Currently it is running on postgresql-8.4 - will postgresql-10 support
> generating plans using multiple CPU c
Hi,
I have a letancy-sensitive legacy application, where the time consumed
by query planning was always causing some headaches.
Currently it is running on postgresql-8.4 - will postgresql-10 support
generating plans using multiple CPU cores to reduce the time required
to generate a single plan?
T
I need to make a view which decorates rows from a parent table with
aggregated values from a child table. I can think of two ways to write it,
one which aggregates the child table to make a new query table and joins
the parent to that, as shown in "view1" below. Or does subselect in the
select li
On Sun, May 21, 2017 at 5:37 PM, Tom Lane wrote:
> Riaan Stander writes:
>> The intended use is use-once. The reason is that the statements might
>> differ per call, especially when we start doing updates. The ideal would
>> be to just issue the sql statements, but I was trying to cut down on
>>
I need to be able to quickly find rows where a column is not null (only a
small percent of the rows will have that column not null).
Should I do:
CREATE INDEX ON table ((col IS NOT NULL)) WHERE col IS NOT NULL
or:
CREATE INDEX ON table (col) WHERE col IS NOT NULL
I'm thinking the first ind
Simon Riggs writes:
> It sounds like you don't know about anonymous code blocks with DO
> https://www.postgresql.org/docs/devel/static/sql-do.html
No, the problem was that there are also some parameters to be passed
in from the application, and DO doesn't take any parameters; so that
would requir
On 22 May 2017 at 09:06, Riaan Stander wrote:
It sounds like you don't know about anonymous code blocks with DO
https://www.postgresql.org/docs/devel/static/sql-do.html
Yes I do know about that feature. My first implemented generated an
anonymous code block, but to my utter dismay once I tr
On 22 May 2017 at 09:06, Riaan Stander wrote:
>> It sounds like you don't know about anonymous code blocks with DO
>> https://www.postgresql.org/docs/devel/static/sql-do.html
>>
>
> Yes I do know about that feature. My first implemented generated an
> anonymous code block, but to my utter dismay
On 22 May 2017 at 03:14, Riaan Stander wrote:
Riaan Stander writes:
The intended use is use-once. The reason is that the statements might
differ per call, especially when we start doing updates. The ideal would
be to just issue the sql statements, but I was trying to cut down on
network call
11 matches
Mail list logo
