2012/10/24 1:12, Alvaro Herrera wrote:
Satoshi Nagayasu escribió:
With this patch, walwriter process and each backend process
would sum up dirty writes, and send it to the stat collector.
So, the value could be saved in the stat file, and could be
kept on restarting.
The statistics could be re
On 10/28/2012 10:50 PM, Peter Geoghegan wrote:
On 28 October 2012 22:35, Jan Wieck wrote:
The amount of WAL generated with full_page_writes=on is quite substantial.
For pgbench for example the ratio 20:1. Meaning with full_page_writes you
write 20x the amount you do without.
Sure, but as alwa
On 28 October 2012 22:35, Jan Wieck wrote:
> The amount of WAL generated with full_page_writes=on is quite substantial.
> For pgbench for example the ratio 20:1. Meaning with full_page_writes you
> write 20x the amount you do without.
Sure, but as always, pgbench pessimises everything by having w
Hi all,
I see there's already a TODO for allowing pg_restore to accept
multiple --table arguments[1], but would folks support adding this
capability to various other commands which currently accept only a
single --table argument, such as clusterdb, vacuumdb, and reindexdb?
Looking at pg_dump, it
On 27 October 2012 00:06, Andres Freund wrote:
> On Thursday, October 18, 2012 09:58:20 PM Alvaro Herrera wrote:
>> Here is version 22 of this patch. This version contains fixes to issues
>> reported by Andres, as well as a rebase to latest master.
>
> Ok, I now that pgconf.eu has ended I am star
On 10/27/2012 2:41 PM, Heikki Linnakangas wrote:
And it's not at all
clear to me that it would perform better than full_page_writes. You're
writing and flushing out roughly the same amount of data AFAICS.
I think this assumption is wrong. full_page_writes=on means we write the
full page conten
Hello
here is updated patch
main change - it doesn't touch psql lexer - like Tom proposed
other points respect Phil's notices
>>
>
> My first review...
>
> Patch applied cleanly to master and make check was fine.
>
> I tested it out and it operates as advertised. There were a couple
> things th
Hey folks,
It seems like right now when you want to create an index concurrently, the
index creation will get canceled if you cancel the statement (i.e. you must
keep your statement open).
Is there a way to "launch" an index creation in the background so that the
statement doesn't need to be k
HI there,
I've committed a tiny bit of code to the postgresql_measures_types project
on github:
git://github.com/aaronsheldon/postgresql_measure_types.git
It faintly shows the direction I'm going in. Over the next few weeks of
work in the evenings I'm going to tackle the to-do list:
1. Writ
On Sat, Oct 27, 2012 at 8:41 PM, Heikki Linnakangas
wrote:
> If the pointers are stored as simple 4-byte integers, you probably could
> assume that they're atomic, and won't be torn.
Actually I think any fixed-size data structure would be fine. We're
worried about storage on disk here, not in mem
On 28 October 2012 09:43, Hannu Krosing wrote:
> test=# select 'NaN'::float = 'NaN'::float as must_be_false;
> must_be_false
> --
> t
> (1 row)
>
> I think that PostgreSQL's behaviour of comparing two
> NaN-s as equal is wrong and Iwe should follow the IEEE 754 spec here
The reason that
On 28 October 2012 10:37, Hannu Krosing wrote:
> On 10/28/2012 11:21 AM, Thomas Munro wrote:
>>
>> On 28 October 2012 09:43, Hannu Krosing wrote:
>>>
>>> This is how PostgreSQL currently works -
>>>
>>> test=# select 'NaN'::float = 'NaN'::float as must_be_false;
>>> must_be_false
>>> --
On 10/28/2012 11:21 AM, Thomas Munro wrote:
On 28 October 2012 09:43, Hannu Krosing wrote:
This is how PostgreSQL currently works -
test=# select 'NaN'::float = 'NaN'::float as must_be_false;
must_be_false
--
t
(1 row)
I think that PostgreSQL's behaviour of comparing two
NaN-s as
On 10/28/2012 11:05 AM, Chris Corbyn wrote:
Would this introduce problems finding rows where the stored value is NaN? You'd
need to add a function or operator to avoid that.
I guess it should behave similar to NULL-s
That is IS NOT DISTINCT FROM should still return true
test=# select NULL IS
On 28 October 2012 09:43, Hannu Krosing wrote:
> This is how PostgreSQL currently works -
>
> test=# select 'NaN'::float = 'NaN'::float as must_be_false;
> must_be_false
> --
> t
> (1 row)
>
> I think that PostgreSQL's behaviour of comparing two
> NaN-s as equal is wrong and Iwe should f
Would this introduce problems finding rows where the stored value is NaN? You'd
need to add a function or operator to avoid that.
Il giorno 28/ott/2012, alle ore 20:43, Hannu Krosing ha scritto:
> This is how PostgreSQL currently works -
>
> test=# select 'NaN'::float = 'NaN'::float as must_be_
This is how PostgreSQL currently works -
test=# select 'NaN'::float = 'NaN'::float as must_be_false;
must_be_false
--
t
(1 row)
I think that PostgreSQL's behaviour of comparing two
NaN-s as equal is wrong and Iwe should follow the IEEE 754 spec here
As per IEEE 754 a NaN behaves simil
17 matches
Mail list logo
