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
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
On 12/31/2013 09:55 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
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
2014-11-10 18:43 GMT+01:00 Eric Ramirez eric.ramirez...@gmail.com:
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
On Mon, Nov 10, 2014 at 10:48 AM, Josh Berkus j...@agliodbs.com wrote:
On 12/31/2013 09:55 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Tom,
There's an abbreviated version of this argument in the comments in
my proposed patch at
On 11/10/2014 10:59 AM, Jeff Janes wrote:
On Mon, Nov 10, 2014 at 10:48 AM, Josh Berkus j...@agliodbs.com wrote:
On 12/31/2013 09:55 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Tom,
There's an abbreviated version of this argument in the comments in
my proposed patch at
On 2014-11-10 10:48:24 -0800, Josh Berkus wrote:
On 12/31/2013 09:55 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
Josh Berkus j...@agliodbs.com writes:
On 11/10/2014 10:59 AM, Jeff Janes wrote:
On Mon, Nov 10, 2014 at 10:48 AM, Josh Berkus j...@agliodbs.com wrote:
Did this patch every make it in? Or did it hang waiting for verification?
It made it in:
commit 4162a55c77cbb54acb4ac442ef3565b813b9d07a
On 11/10/2014 11:11 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 11/10/2014 10:59 AM, Jeff Janes wrote:
On Mon, Nov 10, 2014 at 10:48 AM, Josh Berkus j...@agliodbs.com wrote:
Did this patch every make it in? Or did it hang waiting for verification?
It made it in:
commit
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
On Mon, Nov 10, 2014 at 11:04 AM, Josh Berkus j...@agliodbs.com wrote:
On 11/10/2014 10:59 AM, Jeff Janes wrote:
On Mon, Nov 10, 2014 at 10:48 AM, Josh Berkus j...@agliodbs.com wrote:
Did this patch every make it in? Or did it hang waiting for
verification?
It made it in:
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 at once,
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
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 if that
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
16 matches
Mail list logo
