temp_buffers = 16MB
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/UNLOGGED-TEMPORARY-tables-tp5749477p5749656.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make c
New test with temporary table and unlogged
Total rows 600k
Table size after copy 121MB
temp_buffers / copy speed
16MB - 12999 rows/s
128MB - 13005 rows/s
256MB - 13258 rows/s
512MB - 13399 rows/s
1GB - 13145 rows/s
Unlogged table - 1 rows/s
I don't undestand why previous test showed the d
Steve Crawford wrote
>
> select ',123,456,,7,8.1,0,9'::money;
> money
>
> $12,345,678.11
As an end-user it would seem since a comma (or whatever the locale defines
as a group separator) carries no significant information - it is purely
aesthetic - that ignoring all commas
Jasen Betts writes:
> On 2013-03-26, Tom Lane wrote:
>> The manual says that 'escape' encoding "merely outputs null bytes as
>> \000 and doubles backslashes".
>> (Having said that, I wonder though if "escape" doesn't need more
>> thought. The output is only valid text in SQL_ASCII or single-b
On Fri, Mar 29, 2013 at 10:39 AM, Jasen Betts wrote:
> how confusing is 'EST' ?
> worse than this:
>
> set datestyle to 'sql,dmy';
> set time zone 'Australia/Brisbane';
> select '20130101T00Z'::timestamptz;
> set time zone 'Australia/Sydney';
> select '20130101T00Z'::timestamptz;
> set tim
On 2013-03-28, Gavin Flower wrote:
>
> Hmm... This should optionally apply to time. e.g.
> time_i_got_up_in_the_morning should reflect the time zone where I got up
> - if I got up at 8am NZ time then this should be displayed, not 12pm (12
> noon) to someone in Los Angeles or 3am in Tokyo! (hav
On Thu, Mar 28, 2013 at 2:12 PM, Kevin Grittner wrote:
>> What I want to do is return items that have 'Robocop' or 'Robocop
>> and DVD' or 'Robocop and Collection' or 'Robocop and DVD and
>> collection'
>
> SELECT m.* FROM movies m
> WHERE to_tsvector(m.item_title) @@ to_tsquery('Robocop & (DVD
2013/3/28 CR Lender :
> On 2013-03-28 13:11, Martín Marqués wrote:
>> 2013/3/27 CR Lender :
>>> In this case I was only trying to make sense of an existing database
>>> (8.3). The statistics in pg_stats were way off for some tables, so I
>>> wanted to see if (auto)vacuum and (auto)analyze were bein
On 2013-03-27, Misa Simic wrote:
> --20cf3074d6a0c370ce04d8ef50c1
> Content-Type: text/plain; charset=UTF-8
>
> Hi Clemens,
>
> Well, I am not sure what you mean by polling...
>
> But Example shows - that C app - actually asks all the time to get
> notify... when gets something more then 4 times -
On 2013-03-27, Ken Tanzer wrote:
> --047d7b5da657ecd54004d8e23a90
> Content-Type: text/plain; charset=ISO-8859-1
>
> I've been working on some queries involving multiple unnested columns. At
> first, I expected the number of rows returned would be the product of the
> array lengths, so that this
On 2013-03-26, Tom Lane wrote:
> The manual says that 'escape' encoding "merely outputs null bytes as
> \000 and doubles backslashes".
> (Having said that, I wonder though if "escape" doesn't need more
> thought. The output is only valid text in SQL_ASCII or single-byte
> encodings, otherwise
On 29/03/13 10:13, D'Arcy J.M. Cain wrote:
On 28 Mar 2013 20:50:42 GMT
Jasen Betts wrote:
it actually does that, if you have the locale installed you can set
LC_MONETARY to Japan and get no decimals and a Yen symbol
or to UAE and get three decimals and their currency symbol.
Must have been a
On 03/28/2013 04:36 PM, John R Pierce wrote:
or to another extreme, part of the data, such that different rows could
have different monetary units.(eg, money is implemented as a pair
(currency,amount).eeek, then you'd need exchange rate tables and
such. hahahahaha, what a nightmare.
On 3/28/2013 2:13 PM, D'Arcy J.M. Cain wrote:
I would have rather made that part of the column definition similar to
how we create timestamps with or without timezones. If a column is
tracking Yen it should always be Yen. Y10,000 should never display as
$100.00 just because the locale changes.
On 28 Mar 2013 20:50:42 GMT
Jasen Betts wrote:
> it actually does that, if you have the locale installed you can set
> LC_MONETARY to Japan and get no decimals and a Yen symbol
> or to UAE and get three decimals and their currency symbol.
Must have been added by someone else after I worked on
"Severn, Chris" wrote:
> I have a statement that is like this
>
> SELECT m.* FROM movies m
> WHERE to_tsvector(m.item_title) @@ to_tsquery('Robocop|DVD|Collection')
>
> this works, but it correctly returns all the matching records
> that have any of the query items in them.
>
> What I want t
On 2013-03-28, D'Arcy J.M. Cain wrote:
>
> I would like to see the type handle other situations such as foreign
> (to me) currency, etc. I suppose a positional parameter and a currency
> string setting would handle most of those issues. Technically, the
> money type is a cents type. Everything
I have a statement that is like this
SELECT m.* FROM movies m WHERE to_tsvector(m.item_title) @@
to_tsquery('Robocop|DVD|Collection')
this works, but it correctly returns all the matching records that have any of
the query items in them.
What I want to do is return items that have 'Robocop' or
On 29/03/13 02:28, D'Arcy J.M. Cain wrote:
On Thu, 28 Mar 2013 23:43:23 +1100
Gavan Schneider wrote:
But it appears that the philosophy does not extend to the "money"
type. ...
As the original author of the money type I guess I should weigh in.
select ',123,456,,7,8.1,0,9'::money;
money
On 28/03/13 03:03, Tom Lane wrote:
Gavin Flower writes:
The rule appears to be,
where N_x & N_y are the number of entries returned for x & y:
N_result = is the smallest positive integer that has N_x & N_y as factors.
Right: if there are multiple set-returning functions in a SELECT list,
the nu
CR Lender wrote:
> The database is running on PostgreSQL 8.3.6.
> I've read the manual more carefully now, and I can't see any mention of
> what VACUUM does that VACUUM FULL does not. The point about extreme
> maintainance is taken, but from what I read, VACUUM FULL should include
> everything a
On 2013-03-28 13:11, Martín Marqués wrote:
> 2013/3/27 CR Lender :
>> In this case I was only trying to make sense of an existing database
>> (8.3). The statistics in pg_stats were way off for some tables, so I
>> wanted to see if (auto)vacuum and (auto)analyze were being run.
>> pg_stat_all_tables
salah jubeh wrote:
> Well my question was not very precise, the postgresql version is
> 8.3 which is not supported, so I wanted to migrate to a newer
> version which is 9.1.
>
> I have used pg_dump with -Fc option and I was monitoring the
> pg_restore activity. Normally, the dump and restore ta
> On 27/3/13 at 9:12 AM, Steve Crawford wrote:
>> Thoughts? Is this the "no surprises" way that money input should behave?
I took a quick look at cash_in(), which is what's being complained of
here (not really casting). There are several things that seem like
they could possibly stand to be tight
On 03/28/2013 07:43 AM, Gavan Schneider wrote:
Personally I have ignored the money type in favour of numeric. Money
seemed to do too much behind the scenes for my taste, but, that's me
being lazy as well, I haven't spend much time trying to understand its
features.
You're not the only one. In
On Thu, 28 Mar 2013 23:43:23 +1100
Gavan Schneider wrote:
> >But it appears that the philosophy does not extend to the "money"
> >type. ...
As the original author of the money type I guess I should weigh in.
> >select ',123,456,,7,8.1,0,9'::money;
> >money
> >
> >$12,345,678.11
On 27/3/13 at 9:12 AM, Steve Crawford wrote:
In contrast to certain other open-source databases, PostgreSQL leans
toward protecting data from surprises ...
And long may this continue.
But it appears that the philosophy does not extend to the "money"
type. ...
select ',123,456,,7,8.1,0,9'::m
2013/3/27 CR Lender :
>
>> Also, a VACUUM FULL is an extreme form of
>> maintenance which should rarely be needed; if you find that you
>> need to run VACUUM FULL, something is probably being done wrong
>> which should be fixed so that you don't need to continue to do such
>> extreme maintenance.
>
Thanks for the reply,
Well my question was not very precise, the postgresql version is 8.3 which is
not supported, so I wanted to migrate to a newer version which is 9.1.
I have used pg_dump with -Fc option and I was monitoring the pg_restore
activity. Normally, the dump and restore takes from
30 matches
Mail list logo
