Maybe postgresql (application) layer ping pong.
Enabling system wise timeouts can impact my whole setup including my web
app, thats why it is hard for me to configure them.
On Wed, Apr 17, 2019, 22:12 Francisco Olarte wrote:
> On Wed, Apr 17, 2019 at 4:49 PM Ajay Pratap
> wrote:
> > Correction
On 18/04/2019 18:52, rihad wrote:
Hi. Say there are 2 indexes:
"foo_index" btree (foo_id)
"multi_index" btree (foo_id, approved, expires_at)
foo_id is an integer. Some queries involve all three columns in their
WHERE clauses, some involve only foo_id.
Would it be ok from general perf
Am 18.04.19 um 08:52 schrieb rihad:
Hi. Say there are 2 indexes:
"foo_index" btree (foo_id)
"multi_index" btree (foo_id, approved, expires_at)
foo_id is an integer. Some queries involve all three columns in their
WHERE clauses, some involve only foo_id.
Would it be ok from general
Andreas Kretschmer wrote:
> Am 18.04.19 um 08:52 schrieb rihad:
> > Hi. Say there are 2 indexes:
> >
> > "foo_index" btree (foo_id)
> >
> > "multi_index" btree (foo_id, approved, expires_at)
> >
> >
> > foo_id is an integer. Some queries involve all three columns in their
> > WHERE cla
On 4/18/19 2:14 AM, Andreas Kretschmer wrote:
Am 18.04.19 um 08:52 schrieb rihad:
Hi. Say there are 2 indexes:
"foo_index" btree (foo_id)
"multi_index" btree (foo_id, approved, expires_at)
foo_id is an integer. Some queries involve all three columns in their
WHERE clauses, some in
On 19/04/2019 01:24, Ron wrote:
On 4/18/19 2:14 AM, Andreas Kretschmer wrote:
Am 18.04.19 um 08:52 schrieb rihad:
Hi. Say there are 2 indexes:
"foo_index" btree (foo_id)
"multi_index" btree (foo_id, approved, expires_at)
foo_id is an integer. Some queries involve all three columns
Ajay Pratap writes:
> Enabling system wise timeouts can impact my whole setup including my web
> app, thats why it is hard for me to configure them.
Uh ... who said anything about system-wide timeouts?
The normal way to set this up is to configure the tcp_keepalives_xxx
PG parameters, which will
Andreas Kretschmer writes:
> Am 18.04.19 um 08:52 schrieb rihad:
>> Hi. Say there are 2 indexes:
>>
>> "foo_index" btree (foo_id)
>>
>> "multi_index" btree (foo_id, approved, expires_at)
>>
>>
>> foo_id is an integer. Some queries involve all three columns in
>> their WHERE clauses, some
On 4/18/19 8:45 AM, Gavin Flower wrote:
On 19/04/2019 01:24, Ron wrote:
On 4/18/19 2:14 AM, Andreas Kretschmer wrote:
[snip]
(Prefix compression would obviate the need for this question. Then your
multi-column index would be *much* smaller.)
True, but a multi column index will still be big
On 4/17/19 5:30 PM, Souvik Bhattacherjee wrote:
There are few if any situations where you need to immediately and
completely pass all values from one query to another in the same
transaction where the queries cannot just be combined into a single
statement. Your representative example is one t
Thanks Michel.
However this only works if a is an unique attribute in the table that would
help us to identify tuples that participated in the join. Consider the
following join:
insert into table3 (id, level, empname, salary)
(select t0.cid, t0.level, t1.empname, t2.salary from table0 t0, table1
Well the DELETE is not going to work as c.cid will error as undefined.
> Yes, that's a typo. I haven't tested it out before typing; just wanted to
convey the general idea.
-SB
On Thu, Apr 18, 2019 at 10:50 AM Adrian Klaver
wrote:
> On 4/17/19 5:30 PM, Souvik Bhattacherjee wrote:
> > There are
>
> Thus, what I'm looking for here is way to store the information and then
> pass that information to the next query efficiently.
> For example, is it possible to define a struct of my choice, private to
> the current transaction, that would store the data and then pass it around
> to the next qu
Hi,
I have come across a query that a developer wrote to update a few rows in
table, the query did update the two desired rows but also updated the
rest of the table with the column value as 'false'.
Update tableA set col1 = null and col2 in (1,2);
The query updated col1 to null for the rows whe
On Thursday, April 18, 2019, Vikas Sharma wrote:
>
> The above was run without where clause.
>
There was no where clause thus every row has to be updated by
definition...null and bool evaluates to either false or null since if bool
is false the null doesn’t matter and if bool is true the result
On 4/18/19 9:43 AM, Vikas Sharma wrote:
Hi,
I have come across a query that a developer wrote to update a few rows
in table, the query did update the two desired rows but also updated the
rest of the table with the column value as 'false'.
Update tableA set col1 = null and col2 in (1,2);
Th
On Thu, Apr 18, 2019 at 9:06 AM Michael Lewis wrote:
> Thus, what I'm looking for here is way to store the information and then
>> pass that information to the next query efficiently.
>> For example, is it possible to define a struct of my choice, private to
>> the current transaction, that would
On 4/18/19 11:43 AM, Vikas Sharma wrote:
Hi,
I have come across a query that a developer wrote to update a few rows in
table, the query did update the two desired rows but also updated the
rest of the table with the column value as 'false'.
Update tableA set col1 = null and col2 in (1,2);
T
On 4/17/19 9:38 PM, Julie Nishimura wrote:
Thank you! All works now
Great.
I mentioned upstream about migrating to version newer then 9.4. Given
the amount of work you are putting into this, would you not be better
served by going to a version that has more then ~10 months left on its
commun
Not able to produce this with PG 11.1
If col1 is any type other than boolean, the update statement fails in syntax.
If col1 is boolean, then it updated it correctly. In other words
update col1 = NULL
and col2 in (1,2)
is treated same as
update col1 = NULL
where col2 in (1,2)
Also
Oh wait. I see that it in both cases it did update correct target rows, but
the value of col1 for non matching rows
is different. In the first case (and col2), the non matching rows also got
updated.
So yes, same behavior like yours.
> Sent: Thursday, April 18, 2019 at 2:36 PM
> From: "Ravi K
On 4/18/19 11:36 AM, Ravi Krishna wrote:
Not able to produce this with PG 11.1
If col1 is any type other than boolean, the update statement fails in syntax.
If col1 is boolean, then it updated it correctly. In other words
update col1 = NULL
and col2 in (1,2)
is treated same as
upda
> The above is not the same format as OP's query:
>
> Update tableA set col1 = null and col2 in (1,2);
I did include set in the sql. I typed it wrong here.
On Thu, Apr 18, 2019 at 9:03 AM Souvik Bhattacherjee
wrote:
> Thanks Michel.
>
> However this only works if a is an unique attribute in the table that
> would help us to identify tuples that participated in the join. Consider
> the following join:
>
> insert into table3 (id, level, empname, salar
On 19/04/2019 02:12, Ron wrote:
On 4/18/19 8:45 AM, Gavin Flower wrote:
On 19/04/2019 01:24, Ron wrote:
On 4/18/19 2:14 AM, Andreas Kretschmer wrote:
[snip]
(Prefix compression would obviate the need for this question. Then
your multi-column index would be *much* smaller.)
True, but a mul
On 19/04/2019 01:47, Harald Fuchs wrote:
Andreas Kretschmer writes:
Am 18.04.19 um 08:52 schrieb rihad:
Hi. Say there are 2 indexes:
"foo_index" btree (foo_id)
"multi_index" btree (foo_id, approved, expires_at)
foo_id is an integer. Some queries involve all three columns in
thei
Or just add pid to table3...
> That's an application requirement. So pid cannot be added at will to
table3.
How much development and maintenance effort are you willing to spend here
to gain what is likely to amount to only a bit of efficiency? Many things
are possible if you are going to modify
On 19/04/2019 01:47, Harald Fuchs wrote:
Andreas Kretschmer writes:
Am 18.04.19 um 08:52 schrieb rihad:
Hi. Say there are 2 indexes:
"foo_index" btree (foo_id)
"multi_index" btree (foo_id, approved, expires_at)
foo_id is an integer. Some queries involve all three columns in
thei
On 19/04/2019 14:01, Gavin Flower wrote:
[...]
Also there will be fewer index entries per block for the multi_index,
which is why the I/O count will be higher even in the best case where
there is an equal number of rows referenced by each index entry.
Not sure why my system had this still i
29 matches
Mail list logo
