hi,
in the pgsql documentation
(http://www.postgresql.org/docs/9.1/static/sql-createtrigger.html)
i haven't seen anything referring to: how is affected the data inserted in
the new table by a trigger Before Insert compared with a trigger After
Insert? and anything related to performance
for exam
On 11/10/2014 12:13 PM, Jeff Janes wrote:
> The related problem where the "end" rows are actually needed (e.g. ORDER
> BY...LIMIT) has not been fixed.
>
> My idea to fix that was to check if the row's creation-transaction was in
> the MVCC snapshot (which just uses local memory) before checking i
Hi Matteo,
Thanks for your suggestions, I just run some test with ILIKE and LIKE, and
ILIKE is consistently slower so I think I will keep the Lower functions.
As per your suggestion, I have switched indexes to use GIN type index,
they seem to build/read a bit faster, still the Recheck task contin
Josh Berkus wrote:
> All,
>
> pg version: 9.3.5
> RHEL 6.5
> 128GB/32 cores
> Configured with shared_buffers=16GB
> Java/Tomcat/JDBC application
>
> Server has an issue that whenever we get lock waits (transaction lock
> waits, usually on an FK dependancy) lasting over a minute or more than
> 10
On Mon, Nov 10, 2014 at 11:04 AM, Josh Berkus wrote:
> On 11/10/2014 10:59 AM, Jeff Janes wrote:
> > On Mon, Nov 10, 2014 at 10:48 AM, Josh Berkus wrote:
> >
>
> >> Did this patch every make it in? Or did it hang waiting for
> verification?
> >>
> >
> > It made it in:
> >
> > commit 4162a55c77c
All,
pg version: 9.3.5
RHEL 6.5
128GB/32 cores
Configured with shared_buffers=16GB
Java/Tomcat/JDBC application
Server has an issue that whenever we get lock waits (transaction lock
waits, usually on an FK dependancy) lasting over a minute or more than
10 at once, *all* queries on the server slow
On 11/10/2014 11:11 AM, Tom Lane wrote:
> Josh Berkus writes:
>> On 11/10/2014 10:59 AM, Jeff Janes wrote:
>>> On Mon, Nov 10, 2014 at 10:48 AM, Josh Berkus wrote:
Did this patch every make it in? Or did it hang waiting for verification?
>
>>> It made it in:
>>> commit 4162a55c77cbb54acb4a
Josh Berkus writes:
> On 11/10/2014 10:59 AM, Jeff Janes wrote:
>> On Mon, Nov 10, 2014 at 10:48 AM, Josh Berkus wrote:
>>> Did this patch every make it in? Or did it hang waiting for verification?
>> It made it in:
>> commit 4162a55c77cbb54acb4ac442ef3565b813b9d07a
>> Author: Tom Lane
>> Date
On 2014-11-10 10:48:24 -0800, Josh Berkus wrote:
> On 12/31/2013 09:55 AM, Tom Lane wrote:
> > Josh Berkus writes:
> >> Tom,
> >>> There's an abbreviated version of this argument in the comments in
> >>> my proposed patch at
> >>> http://www.postgresql.org/message-id/11927.1384199...@sss.pgh.pa.us
On 11/10/2014 10:59 AM, Jeff Janes wrote:
> On Mon, Nov 10, 2014 at 10:48 AM, Josh Berkus wrote:
>
>> On 12/31/2013 09:55 AM, Tom Lane wrote:
>>> Josh Berkus writes:
Tom,
> There's an abbreviated version of this argument in the comments in
> my proposed patch at
> http://www.pos
On Mon, Nov 10, 2014 at 10:48 AM, Josh Berkus wrote:
> On 12/31/2013 09:55 AM, Tom Lane wrote:
> > Josh Berkus writes:
> >> Tom,
> >>> There's an abbreviated version of this argument in the comments in
> >>> my proposed patch at
> >>> http://www.postgresql.org/message-id/11927.1384199...@sss.pgh
2014-11-10 18:43 GMT+01:00 Eric Ramirez :
>
> Hi,
> I have created a sample database with test data to help benchmark our
> application. The database has ten million records, and is running on a
> dedicated server(postgres 9.3) with 8GB of RAM. Our queries are pretty
> slow with this amount of da
Tory,
Do you know if your workload involves a lot of lock-blocking,
particularly blocking on locks related to FKs? I'm tracing down a
problem which sounds similar to yours.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-performance mailing list (pgsql-performan
On 12/31/2013 09:55 AM, Tom Lane wrote:
> Josh Berkus writes:
>> Tom,
>>> There's an abbreviated version of this argument in the comments in
>>> my proposed patch at
>>> http://www.postgresql.org/message-id/11927.1384199...@sss.pgh.pa.us
>>> What I'm hoping will happen next is that the complainant
Hi,
I have created a sample database with test data to help benchmark our
application. The database has ten million records, and is running on a
dedicated server(postgres 9.3) with 8GB of RAM. Our queries are pretty
slow with this amount of data and is my job to get them to run to at
acceptable sp
Indeed I could save some IO with noatime. I must say I haven’t found any
recommendation about mount options for postgresql, likely because this is not
encourage. The ones you see are taking from a Oracle cluster configuration
where several nodes see the same files. It's not the case on this setu
16 matches
Mail list logo
