Ioannis Anagnostopoulos writes:
> On 06/08/2012 16:34, Tom Lane wrote:
>> What you should probably be looking for is a hash join plan.
> ...
> Which is a Merge join and not a hash. Any ideas how to make it a hash join?
You might need to ANALYZE the temp table, if you didn't already. Also
it mig
On 06/08/2012 16:34, Tom Lane wrote:
Ioannis Anagnostopoulos writes:
I think this is a pretty good plan and quite quick given the
size of the table (88Million rows at present). However in real
life the parameter where I search for msg_id is not an array of
3
- Original Message -
From: Tom Lane
To: Midge Brown
Cc: pgsql-performance@postgresql.org
Sent: Friday, August 03, 2012 11:26 PM
Subject: Re: [PERFORM] slow query, different plans
"Midge Brown" writes:
> I'm having a problem with a query on our production server, but not
Diff of config files is below. default_statistics_target in both is currently
at the default of 100, though I'm going to try increasing that for this table
as Tom Lane suggested.
-Midge
- Original Message -
From: Greg Williamson
To: pgsql-performance@postgresql.org
Sent: Friday, Aug
Ioannis Anagnostopoulos writes:
> I think this is a pretty good plan and quite quick given the
> size of the table (88Million rows at present). However in real
> life the parameter where I search for msg_id is not an array of
> 3 ids but of 300.000 or more. It is th
They are random as the data are coming from multiple threads that are
inserting in the database. I see what you say about "linking them", and
I may give it a try with the date. The other think that "links" them
together is the 4 georef fields, however at that stage I am trying to
collect statis
Hi Yiannis,
Is there anything linking these ids together, or are the relatively
random? If they are relatively random, the rows are likely to be
sprinkled amongst many blocks and so a seq scan is the fastest. I've
seen similar problems with indexed queries in a multi-tennant database
where t
Hi, my query is very simple:
select
msg_id,
msg_type,
ship_pos_messages.pos_georef1,
ship_pos_messages.pos_georef2,
ship_pos_messages.pos_georef3,
ship_pos_messages.pos_georef4,
obj_id,
ship_speed,
2012/8/6 Magnus Hagander :
> On Mon, Aug 6, 2012 at 4:16 PM, Pavel Stehule wrote:
>> 2012/8/6 Magnus Hagander :
>>> That's not a good way of doing it, since you loose persistent storage.
>>>
>>> Instead, you should set the stats_temp_dir paramter to a filesystem
>>> somewhere else that is tmpfs. T
On Mon, Aug 6, 2012 at 4:16 PM, Pavel Stehule wrote:
> 2012/8/6 Magnus Hagander :
>> That's not a good way of doing it, since you loose persistent storage.
>>
>> Instead, you should set the stats_temp_dir paramter to a filesystem
>> somewhere else that is tmpfs. Then PostgreSQL will automatically
2012/8/6 Magnus Hagander :
> That's not a good way of doing it, since you loose persistent storage.
>
> Instead, you should set the stats_temp_dir paramter to a filesystem
> somewhere else that is tmpfs. Then PostgreSQL will automatically move
> the file to and from the main data directory on start
That's not a good way of doing it, since you loose persistent storage.
Instead, you should set the stats_temp_dir paramter to a filesystem
somewhere else that is tmpfs. Then PostgreSQL will automatically move
the file to and from the main data directory on startup and shutdown,
so you get both the
12 matches
Mail list logo
