Re: [PERFORM] Will Postgres ever lock with read only queries?

Chris writes: > Robert James wrote: >> Hi. I'm seeing some weird behavior in Postgres. I'm running read only >> queries (SELECT that is - no UPDATE or DELETE or INSERT is happening at >> all). I can run one rather complicated query and the results come >> back... eventually. Likewise with a

Re: [PERFORM] Will Postgres ever lock with read only queries?

Robert James wrote: Hi. I'm seeing some weird behavior in Postgres. I'm running read only queries (SELECT that is - no UPDATE or DELETE or INSERT is happening at all). I can run one rather complicated query and the results come back... eventually. Likewise with another. But, when I run bot

Re: [PERFORM] Will Postgres ever lock with read only queries?

On 07/27/2009 08:54 PM, Robert James wrote: Hi. I'm seeing some weird behavior in Postgres. I'm running read only queries (SELECT that is - no UPDATE or DELETE or INSERT is happening at all). I can run one rather complicated query and the results come back... eventually. Likewise with anoth

[PERFORM] Will Postgres ever lock with read only queries?

Hi. I'm seeing some weird behavior in Postgres. I'm running read only queries (SELECT that is - no UPDATE or DELETE or INSERT is happening at all). I can run one rather complicated query and the results come back... eventually. Likewise with another. But, when I run both queries at the same ti

Re: [PERFORM] select query performance question

Hi Thomas, How is 'messungen_v_dat_2009_04_13_gtyp_minute_tag_idx' defined? What is the row count for the table? Mike Hi, subject is the following type of query needed in a function to select data: SELECT ' 13.04.2009 12:00:00 ' AS zeit,

Re: [PERFORM] hyperthreaded cpu still an issue in 8.4?

On 7/27/09 11:05 AM, "Dave Youatt" wrote: > On 01/-10/-28163 11:59 AM, Greg Smith wrote: >> On Tue, 21 Jul 2009, Doug Hunley wrote: >> > Also, and this is getting maybe too far off topic, beyond the buzzwords, > what IS the new "hyperthreading" in Nehalems? -- opportunistic > superpipelined c

Re: [PERFORM] More speed counting rows

> How "up to date" do the counts need to be? If the count takes 4 > seconds, can you run it every minute and store the counts in a table for > retrieval by the HTTP requests? Now, I am storing integer value for filter in memory with timeout, but in busy server, system sure crash without syste

Re: [PERFORM] hyperthreaded cpu still an issue in 8.4?

On 01/-10/-28163 11:59 AM, Greg Smith wrote: > On Tue, 21 Jul 2009, Doug Hunley wrote: > >> Just wondering is the issue referenced in >> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php >> is still present in 8.4 or if some tunable (or other) made the use of >> hyperthreading a

Re: [PERFORM] hyperthreaded cpu still an issue in 8.4?

On Mon, 27 Jul 2009, Dave Youatt wrote: Do you think it's due to the new internal interconnect, that bears a strong resemblance to AMD's hypertransport (AMD's buzzword for borrowing lots of interconnect technology from the DEC alpha (EV7?)), or Intel fixing a not-so-good initial implementation

Re: [PERFORM] More speed counting rows

On Mon, Jul 27, 2009 at 5:06 AM, Developer wrote: > Hello, > > I am trying to optimize the count of files when I am using filters > (select by some row/s parameter/s) > My question is: > Any method for indirect count like ordered indexes + quadratic count? > Any module? > Any suggestion? If all yo

Re: [PERFORM] More speed counting rows

Developer wrote: Hello, I am trying to optimize the count of files when I am using filters (select by some row/s parameter/s) In this case I think that postgresql really count all files. Resulting in unacceptable times of 4 seconds in http server response. Triggers+store in this case do not see

Re: [PERFORM] select query performance question

Thomas Zaksek wrote: > Is this query plan near to optimal or are their any serious flaws? I didn't see any problem with the query, but with the information provided, we can't really tell if you need to reconfigure something, or maybe add an index. The plan generated for the query is doing a

Re: [PERFORM] select query performance question

On Mon, 27 Jul 2009, Thomas Zaksek wrote: Nested Loop (cost=0.00..66344.47 rows=4750 width=10) (actual time=134.160..19574.228 rows=4148 loops=1) -> Index Scan using messungen_v_dat_2009_04_13_gtyp_minute_tag_idx on messungen_v_dat_2009_04_13 m (cost=0.00..10749.14 r

Re: [PERFORM] Can Postgres use an INDEX over an OR?

27 липня 2009 р. 17:18 Tom Lane написав: > =?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= writes: > > Actually what I am talking about is to make OR with UNION (or UNION-like > > because it's a little different depending on input rows uniqueness) as an > > option. All of OR parts can use/not use differen

Re: [PERFORM] select query performance question

Hello maybe is wrong tip, but your function like de* should be slow. What is time of query without calling these functions? Pavel Stehule 2009/7/27 Thomas Zaksek : > Hi, > subject is the following type of query needed in a function to select data: > > SELECT ' 13.04.2009 12:00:00 ' AS zeit, > >

Re: [PERFORM] Can Postgres use an INDEX over an OR?

=?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= writes: > Actually what I am talking about is to make OR with UNION (or UNION-like > because it's a little different depending on input rows uniqueness) as an > option. All of OR parts can use/not use different strategies (including > multiple different idexes

[PERFORM] select query performance question

Hi, subject is the following type of query needed in a function to select data: SELECT ' 13.04.2009 12:00:00 ' AS zeit, 'M' AS ganglinientyp

Re: [PERFORM] More speed counting rows

On Mon, Jul 27, 2009 at 3:06 AM, Developer wrote: > Hello, > > I am trying to optimize the count of files when I am using filters > (select by some row/s parameter/s) > > In this case I think that postgresql really count all files. > Resulting in unacceptable times of 4 seconds in http server respo

Re: [PERFORM] Can Postgres use an INDEX over an OR?

27 липня 2009 р. 15:02 Robert Haas написав: > > The problem, though, is that it won't ALWAYS be right to implement OR > using UNION, so you have to have some way of deciding which is better. > That's easy - you propose both ways to planner and it's up to it to decide. Yes, it can decide wrong wa

Re: [PERFORM] Can Postgres use an INDEX over an OR?

2009/7/27 Віталій Тимчишин : > > > 27 липня 2009 р. 13:53 Robert Haas написав: >> >> Hmm.  What you're suggesting here is that we could consider >> implementing OR conditions by rescanning the inner side for each index >> qual and then unique-ifying the results on the index column.  That's >> prob

Re: [PERFORM] Can Postgres use an INDEX over an OR?

27 липня 2009 р. 13:53 Robert Haas написав: > > Hmm. What you're suggesting here is that we could consider > implementing OR conditions by rescanning the inner side for each index > qual and then unique-ifying the results on the index column. That's > probably possible, but it doesn't sound eas

Re: [PERFORM] Very big insert/join performance problem (bacula)

>>> It really has very little impact. It only affects index scans, and >>> even then only if effective_cache_size is less than the size of the >> table. >>> >>> Essentially, when this kicks in, it models the effect that if you are >>> index scanning a table much larger than the size of your cache,

Re: [PERFORM] Can Postgres use an INDEX over an OR?

2009/7/20 Віталій Тимчишин : > 20 липня 2009 р. 11:02 Chris написав: >> >> Віталій Тимчишин wrote: >>> >>> >>> 2009/7/20 Robert James >> > >>> >>> >>>    Hi. I notice that when I do a WHERE x, Postgres uses an index, and >>>    when I do WHERE y, it does so as well,

[PERFORM] More speed counting rows

Hello, I am trying to optimize the count of files when I am using filters (select by some row/s parameter/s) In this case I think that postgresql really count all files. Resulting in unacceptable times of 4 seconds in http server response. Triggers+store in this case do not see very acceptable, b