Claudio Freire writes:
> On Thu, Nov 3, 2011 at 4:29 PM, Claudio Freire wrote:
>> Next time I find it blocking, I will check pg_locks directly and post
>> the output.
> Here it is, two instances of the query, while blocked:
Hmm ... definitely seems that you're not blocked on a FOR UPDATE tuple
On 11/03/2011 09:40 AM, Robert Haas wrote:
On Thu, Nov 3, 2011 at 11:31 AM, Rodrigo Gonzalez
wrote:
El 03/11/11 11:42, Robert Haas escribió:
On Fri, Oct 28, 2011 at 9:39 AM, CS DBA wrote:
No parameters, one of them looks like this:
[ code snippet ]
It's hard to believe this is the real c
Jay Levitt writes:
>
>
> What other info can I
> provide? id is int, gender is varchar(255), and it's happening on
> 9.0.4...
> [ etc etc ]
Please don't send HTML-only email to these lists.
Anyway, the answer seems to be that inline_set_returning_function needs
some work to handle cases wi
Am 03.11.2011 17:08, schrieb Tomas Vondra:
On 3 Listopad 2011, 16:02, Mario Weilguni wrote:
No doubt about that, querying tables using conditions on array columns is
not the best direction in most cases, especially when those tables are
huge.
Still, the interesting part here is that the OP clai
On Thu, Nov 3, 2011 at 4:29 PM, Claudio Freire wrote:
> Next time I find it blocking, I will check pg_locks directly and post
> the output.
Here it is, two instances of the query, while blocked:
select * from pg_locks where pid = 22636;
locktype| database | relation | page | tuple | virt
On Thu, Nov 3, 2011 at 3:45 PM, Tom Lane wrote:
> Claudio Freire writes:
>> But I cannot figure out which transaction it would be. There *are*, in
>> fact, connections in state, which makes me think
>> those would be the culprit. But for the life of me, I cannot make
>> sense of the pg_locks vie
What other info can I
provide? id is int, gender is varchar(255), and it's happening on
9.0.4...
Tom Lane
November 3, 2011
2:41 PM
Jay Levitt writes:
I'm confused. I have a now-trivial SQL function that, unrestricted, would
scan my whole users table. When I pas
Claudio Freire writes:
> The same query, without FOR UPDATE, takes just 68 milliseconds.
> With the FOR UPDATE, it takes like half a minute or more to finish.
> Now, I understand the for update part may be blocking on some other
> transaction, and it's probably the case.
Yeah, that's what I'd gu
Jay Levitt writes:
> I'm confused. I have a now-trivial SQL function that, unrestricted, would
> scan my whole users table. When I paste the body of the function as a
> subquery and restrict it to one row, it only produces one row. When I paste
> the body of the function into a view and rest
[Please keep the list copied.]
siva palanisamy wrote:
> Could you pls guide me on how to minimize time consumption? I've
> postgresql 8.1.4; Linux OS.
Well, the first thing to do is to use a supported version of
PostgreSQL. More recent releases perform better, for starters.
http://wiki.pos
On Thu, Nov 3, 2011 at 2:51 PM, Claudio Freire wrote:
> What other information should I provide?
Forgot all the usual details:
Server is postgresql 9.0.3, running in linux, quite loaded (load
average ~7), WAL on raid 1 2 spindles, data on raid 10 4 spindles, 16G
RAM.
Could it be high contention
Hi list,
I've been experiencing a weird performance issue lately.
I have a very simple (and usually very fast) query:
SELECT track_logs.id
FROM track_logs
WHERE track_logs.track_id = AND track_logs.track_status_id =
1 AND track_logs.date >= now() - interval '1 hours'
FOR UPDATE
Whose pla
I'm confused. I have a now-trivial SQL function that, unrestricted, would
scan my whole users table. When I paste the body of the function as a
subquery and restrict it to one row, it only produces one row. When I paste
the body of the function into a view and restrict it to one row, it produ
On 03/11/11 09:22, Igor Neyman wrote:
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Wednesday, November 02, 2011 11:13 AM
To: Tom Lane
Cc: Jay Levitt; pgsql-performance@postgresql.org
Subject: Re: Guide to PG's capabilities for inlining, predicate
hoisting, f
On Wed, Nov 2, 2011 at 11:13 AM, Robert Haas wrote:
> […] Perhaps we could let people say
> something like WITH x AS FENCE (...) when they want the fencing
> behavior, and otherwise assume they don't (but give it to them anyway
> if there's a data-modifying operation in there).
>
I would love t
On Fri, Oct 28, 2011 at 14:02, Albe Laurenz wrote:
> Without SSL the SELECT finished in about a second,
> with SSL it took over 23 seconds (measured with
> \timing in psql).
When you query with psql, it requests columns in text format. Since
bytea hex-encodes its value if output is text, this mea
On 3 Listopad 2011, 16:52, siva palanisamy wrote:
> I basically have 3 tables. One being the core table and the other 2 depend
> on the 1st. I have the requirement to add upto 7 records in the
> tables.
> I do have constraints (primary & foreign keys, index, unique etc) set for
> the tables. I
On 3 Listopad 2011, 16:02, Mario Weilguni wrote:
> Am 02.11.2011 08:12, schrieb Mohamed Hashim:
>> Dear All
>>
>> Thanks for your suggestions & replies.
>>
>> The below are the sample query which i put for particular one bill_id
>>
>> EXPLAIN ANALYZE SELECT abd.bill_no as
>> bill_no,to_char(abd.bil
siva palanisamy wrote:
> I basically have 3 tables. One being the core table and the other
> 2 depend on the 1st. I have the requirement to add upto 7
> records in the tables. I do have constraints (primary & foreign
> keys, index, unique etc) set for the tables. I can't go for bulk
> import
On 2011-11-02 16:06, Magnus Hagander wrote:
On Wed, Nov 2, 2011 at 16:04, Yeb Havinga wrote:
On 2011-11-02 15:06, Kevin Grittner wrote:
Yeb Havingawrote:
I'm now contemplating not using the 710 at all. Why should I not
buy two 6Gbps SSDs without supercap (e.g. Intel 510 and OCZ Vertex
3
I basically have 3 tables. One being the core table and the other 2 depend
on the 1st. I have the requirement to add upto 7 records in the tables.
I do have constraints (primary & foreign keys, index, unique etc) set for
the tables. I can't go for bulk import (using COPY command) as there is no
On Thu, Nov 3, 2011 at 11:31 AM, Rodrigo Gonzalez
wrote:
> El 03/11/11 11:42, Robert Haas escribió:
>
> On Fri, Oct 28, 2011 at 9:39 AM, CS DBA wrote:
>
> No parameters, one of them looks like this:
>
> [ code snippet ]
>
> It's hard to believe this is the real code, because SELECT without
> INT
On Tue, Oct 25, 2011 at 5:09 AM, Mohanaraj Gopala Krishnan
wrote:
> I have a query that runs a lot slower (~5 minutes) when I run it with
> the default enable_nestloop=true and enable_nestloop=false (~10 secs).
> The actual query is available here http://pastie.org/2754424 . It is a
> reporting qu
El 03/11/11 11:42, Robert Haas escribió:
On Fri, Oct 28, 2011 at 9:39 AM, CS DBA wrote:
No parameters, one of them looks like this:
[ code snippet ]
It's hard to believe this is the real code, because SELECT without
INTO will bomb out inside a PL/pgsql function, won't it?
But he's using CR
Am 02.11.2011 08:12, schrieb Mohamed Hashim:
Dear All
Thanks for your suggestions & replies.
The below are the sample query which i put for particular one bill_id
EXPLAIN ANALYZE SELECT abd.bill_no as
bill_no,to_char(abd.bill_date,'dd/mm/') AS date,mp.product_desc as
product_desc,std.qua
On Thu, Nov 03, 2011 at 03:48:11PM +0100, Albe Laurenz wrote:
>
> I experimented some more on a recent system (RHEL6, OpenSSL 1.0.0-fips),
> and it is as you say. Disabling OpenSSL compression in the source (which
> is possible since OpenSSL 1.0.0) does not give me any performance
> improvement.
>
Merlin Moncure wrote:
We selected a 30MB bytea with psql connected with
"-h localhost" and found that it makes a huge
difference whether we have SSL encryption on or off.
Without SSL the SELECT finished in about a second,
with SSL it took over 23 seconds (measured with
On Fri, Oct 28, 2011 at 9:39 AM, CS DBA wrote:
> No parameters, one of them looks like this:
>
> [ code snippet ]
It's hard to believe this is the real code, because SELECT without
INTO will bomb out inside a PL/pgsql function, won't it?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
On 2011-11-03 15:31, Shaun Thomas wrote:
On 11/03/2011 04:38 AM, Yeb Havinga wrote:
Both comparable near 10K tps.
That's another thing I was wondering about. Why are we talking about
Vertex 2 Pro's, anyway? The Vertex 3 Pros post much better results and
are still capacitor-backed.
Not f
On 11/03/2011 04:38 AM, Yeb Havinga wrote:
Both comparable near 10K tps.
That's another thing I was wondering about. Why are we talking about
Vertex 2 Pro's, anyway? The Vertex 3 Pros post much better results and
are still capacitor-backed.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blv
On 11/02/2011 09:04 PM, Scott Marlowe wrote:
Take a look here:
http://tech.jonathangardner.net/wiki/PostgreSQL/Materialized_Views
Not sure materialized views are the approach I would take here. We
actually see a lot of these kinds of queries with giant result sets,
here. If they actually nee
On Thu, Nov 3, 2011 at 4:38 AM, Yeb Havinga wrote:
> On 2011-11-02 22:08, Merlin Moncure wrote:
>>
>> On Wed, Nov 2, 2011 at 3:45 PM, Yeb Havinga wrote:
>>>
>>> Intel latency graph at http://imgur.com/Hh3xI
>>> Ocz latency graph at http://imgur.com/T09LG
>>
>> curious: what were the pgbench resul
> -Original Message-
> From: Craig Ringer [mailto:ring...@ringerc.id.au]
> Sent: Thursday, November 03, 2011 5:07 AM
> To: Igor Neyman
> Cc: Robert Haas; Tom Lane; Jay Levitt;
pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Guide to PG's capabilities for inlining,
> predicate hois
On 11/03/2011 04:22 AM, Igor Neyman wrote:
Hints here we come :)
Pfft! No more than `VOLATILE' vs `STABLE' vs `IMMUTABLE'. It's a
semantic difference, not just a performance hint.
That said, I'm not actually against performance hints if done sensibly.
--
Craig Ringer
--
Sent via pgsq
On 2011-11-02 22:08, Merlin Moncure wrote:
On Wed, Nov 2, 2011 at 3:45 PM, Yeb Havinga wrote:
Intel latency graph at http://imgur.com/Hh3xI
Ocz latency graph at http://imgur.com/T09LG
curious: what were the pgbench results in terms of tps?
merlin
Both comparable near 10K tps.
-- Yeb
--
S
35 matches
Mail list logo
