Hi Experts,
As in the example below, i think the plan which hash table is created on
testtbl2 (the fewer tuples) should be choosen.
Because creating of hash table should faster in testtbl2. But it did not.
I have tried to change the ordering of table by tuning parameter even if
using
Hi,
Basically I wanted to do a partial update inside pg (9.5), but it seems
that a partial update fails when not all of constraint is fulfilled (such
as the not null constraint)
Below are the sql queries I used,
CREATE TABLE jobs (
id integer PRIMARY KEY,
employee_name TEXT NOT NULL,
On Fri, Nov 18, 2016 at 10:16 AM, Paul Jungwirth <
p...@illuminatedcomputing.com> wrote:
> But is there a better way?
Nothing that would be more readable nor likely more performant.
When performing aggregation it is necessary to limit the scope of the query
to only whatever it is you are
Hi All,
I've noticed in the past that doing aggregates while joining to more
than one table can sometimes give you unintended results. For example,
suppose I have three tables: products, sales, and resupplies. In sales I
track what I sell, and in resupplies I track my own purchases to
I just ran EXPLAIN ANALYZE, please see images attached. Field doesn't have
a index.
Em sex, 18 de nov de 2016 às 12:16, vinny escreveu:
> On 2016-11-18 15:06, William Ivanski wrote:
> > Hi,
> >
> > I recently did major improvements on perfomance on our routines by
> > simply
On Thu, Nov 17, 2016 at 8:08 PM, Rakesh Kumar
wrote:
> I noticed that as I scale from 5 to 10 to 20 to 40, the TPS starts falling
> almost linearly :
>
> with 5, TPS was doing 639
> with 10 TPS was down to 490
> with 20 TPS was down to 280
> and so on.
Are the TPS
On Thu, 17 Nov 2016 08:26:59 -0900
Israel Brewster wrote:
> > On Nov 16, 2016, at 4:24 PM, Adrian Klaver
> > wrote:
> >
> > On 11/16/2016 04:51 PM, Israel Brewster wrote:
> >> I've been playing around with streaming replication, and
On 2016-11-18 15:06, William Ivanski wrote:
Hi,
I recently did major improvements on perfomance on our routines by
simply removing the call for trim functions on specific bottlenecks.
Please see images attached for a simple example.
I'm using PostgreSQL version 9.5.5-1.pgdg80+1 on Debian 8.6.
Hi,
I recently did major improvements on perfomance on our routines by simply
removing the call for trim functions on specific bottlenecks. Please see
images attached for a simple example.
I'm using PostgreSQL version 9.5.5-1.pgdg80+1 on Debian 8.6. Someone knows
if it's a bug on trim function?
> On Thu, Nov 17, 2016 at 7:09 PM, Mark Anns wrote:
> > Can u explain this statement "check whether the scan qualifier can be
> > executable on GPU device"
> >
> > What are the scan qualifiers?
> >
> > How to determine whether they are device executable or not?
> >
> >
> Can u explain this statement "check whether the scan qualifier can be
> executable on GPU device"
>
> What are the scan qualifiers?
>
SELECT * FROM my_table WHERE x > 20 AND memo LIKE '%abc%';
This is scan qualifier.
> How to
A glaring weakness in Postgresql for production systems is that the
administrator has no way of controlling what types of logs go where. There
are at least two types of logs: errors and statement logs. (I could also
add: connection, syntax error, query duration, audit). It has becomes
increasingly
Hi,
On 16.11.2016 11:54, cen wrote:
Hi
I am seeking some clarification in regard to full text search across
multiple tables and what the best approach is. Documentation talks about
two approaches when it comes to building a document: on-the-fly concat
of columns and a dedicated tsv column
13 matches
Mail list logo