"Midge Brown" writes:
> I'm having a problem with a query on our production server, but not on a
> laptop running a similar postgres version with a recent backup copy of the
> same table. I tried reindexing the table on the production server, but it
> didn't make any difference. Other queries o
Midge --
Sorry for top-quoting -- challenged mail.
Perhaps a difference in the stats estimates -- default_statistics_target ?
Can you show us a diff between the postgres config files for each instance ?
Maybe something there ...
Greg Williamson
>
> From: Midg
I'm having a problem with a query on our production server, but not on a laptop
running a similar postgres version with a recent backup copy of the same table.
I tried reindexing the table on the production server, but it didn't make any
difference. Other queries on the same table are plenty fas
>> This is poor design on Linux's part, since even the distant RAM is
>> faster than disk. For now, we've been disabling zone_reclaim entirely.
>
> I haven't run into this, but we were running ubuntu 10.04 LTS. What
> kernel were you running when this happened? I'd love to see a test
> case on
On Fri, Aug 3, 2012 at 4:30 PM, Josh Berkus wrote:
> On 7/30/12 10:09 AM, Scott Marlowe wrote:
>> I think the zone_reclaim gets turned on with a high ratio. If the
>> inter node costs were the same, and the intranode costs dropped in
>> half, zone reclaim would likely get turned on at boot time.
On 7/30/12 10:09 AM, Scott Marlowe wrote:
> I think the zone_reclaim gets turned on with a high ratio. If the
> inter node costs were the same, and the intranode costs dropped in
> half, zone reclaim would likely get turned on at boot time.
We've been seeing a major problem with zone_reclaim and
So you took two distinct points in time, threw away some critical
information, and are surprised why they are now equal?
Well, I did not want to throw away any information. The actual
representation could be something like:
"2012-11-04 01:30:00-08 in Europe/Budapest, Winter time"
and
"2012-
On 08/03/2012 10:21 AM, Laszlo Nagy wrote:
All the above are the exact same point in time merely stated as
relevant to each location. Note that given a timestamp with time zone
and a zone, PostgreSQL returns a timestamp without time zone (you
know the zone since you specified it).
Yes, I kn
All the above are the exact same point in time merely stated as
relevant to each location. Note that given a timestamp with time zone
and a zone, PostgreSQL returns a timestamp without time zone (you know
the zone since you specified it).
Yes, I know the zone. But I don't know the offset fro
I tried creating the following index:
CREATE INDEX messageq17
ON messageq_table
USING btree
(staff_ty, staff_id, entity_id)
WHERE inactive = false;
'inactive = false' (active would be much easy but this is legacy) records
should make up a smaller proportion of the overall dataset (and mu
Russell Keane wrote:
> "log_min_duration_statement";"1ms"
> "shared_buffers";"32MB"
> "work_mem";"1MB"
Those are pretty low values even for a 4GB machine. I suggest the
following changes and additions, based on the fact that you seem to
have the active portion of the database fully cached.
Settings query:
"version";"PostgreSQL 9.0.4, compiled by Visual C++ build 1500, 32-bit"
"bytea_output";"escape"
"client_encoding";"UNICODE"
"lc_collate";"English_United Kingdom.1252"
"lc_ctype";"English_United Kingdom.1252"
"listen_addresses";"*"
"log_destination";"stderr"
"log_duration";"off"
"log
You're right, a lot of information is missing but I'm unsure that the other
information will make too much difference.
I could drop all the other indexes on the table which aren't used here and the
queries would still use the indexes they are currently using.
I appreciate the idea that a boolean
On Thu, Aug 2, 2012 at 4:54 PM, Russell Keane wrote:
> ** **
>
> Using PG 9.0 and given 2 queries (messageq_current is a view on the
> messageq_table):
>
> ** **
>
> select entity_id from messageq_current
>
> where entity_id = 123456;
>
> ** **
>
> select entity_id from messageq_curre
14 matches
Mail list logo
