( Oracle_FDW ?, flat files ?, ...)
Thanks in advance
Best Regards
[cid:image002.png@01D3434B.11DE8400]
Didier ROS
DSP/CSP IT-DMA/Solutions Groupe EDF/Expertise Applicative
Expertise SGBD
Mail : didier@edf.fr
Ce message et toutes les pièces jointes (ci-après le 'Message') sont
Hi
On Thu, Apr 2, 2015 at 3:52 PM, Pietro Pugni wrote:
>
> I’ve searched just now what a collation is because I’ve never explicitly
> used one before, so I think it uses the default one.
>
>
> What's the output of free and sysctl -a | grep vm.zone_reclaim_mode
>
> Search the mailing list for zon
Hi,
On Thu, Apr 2, 2015 at 12:47 PM, Pietro Pugni wrote:
> Hi Jeff,
> thank you for your response.
> I’m using Postgres 9.0 on MacMini because I’ve noticed that it’s quite fast
> compared to different Ubuntu machines on which I’ve worked with different
> (and more performant) hardware.
> The buil
Hi,
On Wed, Mar 18, 2015 at 12:21 PM, Steven Jones
wrote:
> Hi,
> iostat -x snapshot:
>
> avg-cpu: %user %nice %system %iowait %steal %idle
>0.500.002.35 15.090.00 82.05
>
> Device: rrqm/s wrqm/s r/s w/srkB/swkB/s avgrq-sz
> avgqu-sz
On Thu, Sep 18, 2014 at 11:10 PM, Mkrtchyan, Tigran
wrote:
>
>
> - Original Message -
>> From: "Mark Kirkwood"
>> To: "Merlin Moncure" , "Tigran Mkrtchyan"
>>
>> Cc: "postgres performance list"
>> Sent: Thursday, September 18, 2014 10:56:36 PM
>> Subject: Re: [PERFORM] postgres 9.3 vs.
ant to bring up, why the planner would do that?
> Instead of
> > scanning over the "event_log_pkey"?
> >
>
Maybe there's a bug but I don't think so, Postgresql optimizer is strongly
bias toward uncorrelated data but in your case log_id and event are highly
correlated, right?
With your example it has to chose between:
1- play safe and use event_log_pkey, scan 39502 rows and select the
smallest event.
2- use event_data_search, 4 000 000 rows, 40 000 with a log_id in the
interval thus win big and find one in the first 100 scanned rows or lose
big and scan 4 000 000 rows.
With uncorrelated data 2- is 400 time faster than 1-, 100 rows vs 40 000.
Postgresql is a high stake gambler :)
Didier
Hi
On Wed, Sep 25, 2013 at 1:30 AM, Jeff Janes wrote:
> On Tue, Sep 24, 2013 at 11:03 AM, didier wrote:
>
>>
>> As a matter of fact you get the same slow down after a rollback until
>> autovacuum, and if autovacuum can't keep up...
>>
>
> Have you expe
eason but you can get the same slow down with only one
client and a bigger insert.
The issue is that a btree search for one value degenerate to a linear
search other 1000 or more tuples.
As a matter of fact you get the same slow down after a rollback until
autovacuum, and if autovacuum can't keep up...
Didier
