his though.
best regards,
Marc Mamin
uot;sql" listed as reserved keyword.
best regards,
Marc Mamin
ts caveat:
create temp table t( a int,b int);
insert into t select
1 as b,
2 as a;
select * from t ...
regards,
Marc Mamin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-1] == 7
>array[~2:~-2] == {3,4,5,6}
>
>What do you think?
Hi,
~ is the bitwise NOT operator.
so array[~n:~m] has a current meaning. Not very useful though.
It would be better to choose another character.
my 2 pence,
Marc Mamin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
eously.
Our servers have 40-60 GB RAM , ca. 12 CPUs and we set maintenance mem to 1-2
GB for this.
If the create index themselves start using parallelism, I guess that we might
need to review our workflow...
best regards,
Marc Mamin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On 2015-08-19 AM 02:57, Marc Mamin wrote:
2. Creating a partition of a partitioned table
CREATE TABLE table_name
PARTITION OF partitioned_table_name
FOR VALUES values_spec;
Where values_spec is:
listvalues: [IN] (val1, ...)
Would it make sense to allow one complementary partition
: [[NOT] IN] (val1, ...)
I've thought a few times about moving data with some most common values to
dedicated partitions
and keeping the rest in a separate one...
best regards,
Marc Mamin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
, file4
regards,
Marc Mamin
2015-07-28 10:43 GMT+02:00 Marc Mamin m.ma...@intershop.de:
2015-07-28 5:24 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com:
2015-07-27 21:57 GMT+02:00 Andrew Dunstan and...@dunslane.net:
On 07/27/2015 02:53 PM, Pavel Stehule wrote
in pg_backup_tar.c
that refer to the compression although not supported (except for blob ?)
(C programming is beyond my capabilities, I can roughly read simple code ... )
regards,
Marc Mamin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Sat, Jul 25, 2015 at 11:09 PM, Marc Mamin m.ma...@intershop.de wrote:
On Sat, Jul 25, 2015 at 9:56 PM, Andrew Dunstan and...@dunslane.net wrote:
On 07/25/2015 03:20 AM, Andrew Dunstan wrote:
On 07/25/2015 02:34 AM, Marc Mamin wrote:
Andrew Dunstan and...@dunslane.net writes:
Hmm
level
And maybe a quick notice for planet Postgres to highlight the modification of
the default behavior.
(I' haven't a blog myself ...)
IMHO a slightly higher default would help spare some hardware out there...
regards,
Marc Mamin
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Sat, Jul 25, 2015 at 9:56 PM, Andrew Dunstan and...@dunslane.net wrote:
On 07/25/2015 03:20 AM, Andrew Dunstan wrote:
On 07/25/2015 02:34 AM, Marc Mamin wrote:
Andrew Dunstan and...@dunslane.net writes:
Hmm. Yeah. It looks like commit
a7ad5cf0cfcfab8418000d652fa4f0c6ad6c8911
I propose to tighten pg_dump's rules so that only 0..9 are accepted as
arguments for -Z, and in compress_io.c:cfopen(), if compression is
equal to Z_DEFAULT_COMPRESSION, not add any explicit compression value
to the mode, thus using the zlib default.
As per attached patch.
Comments?
, as though it had been fed through gzip;
but the default is not to compress.
The tar archive format currently does not support compression at all.
shouldn't that be changed to
- For the custom archive format
+ For the directory and custom archive formats
best regards,
Marc
repository of about 1TB within a few weeks if we
hadn't noticed it.
regards,
Marc mamin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 16, 2015 at 12:42 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hi
can we support multiple -c option?
Why? Because some statements like VACUUM cannot be used together with any
other statements with single -c option. The current solution is using echo
and pipe op, but it is
-Original Message-
From: Josh Berkus [mailto:j...@agliodbs.com]
Sent: Dienstag, 7. Juli 2015 02:04
On 07/06/2015 12:20 AM, Marc Mamin wrote:
There seems to be no fence against useless BRIN indexes that
would allow a fallback on a table scan.
But the time overhead remind
that would allow a
fallback on a table scan.
But the time overhead remind small :)
best regards,
Marc Mamin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
So please be cautious about disallowing it too abruptly.
Back-patching a change that disallow our current architecture could prevent us
to apply minor releases for a while...
regards,
Marc Mamin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
From: Ali Akbar [mailto:the.ap...@gmail.com]
Sent: Freitag, 6. Juni 2014 03:44
Subject: Re: [HACKERS] pivot aggregation with a patched intarray
2014-06-05 17:18 GMT+07:00 Marc Mamin m.ma...@intershop.de:
I'm thinking about adding a final function to my aggregate that would
replace zero
-Original Message-
From: Ali Akbar [mailto:the.ap...@gmail.com]
Sent: Donnerstag, 5. Juni 2014 01:12
To: Marc Mamin
Cc: Michael Paquier; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pivot aggregation with a patched intarray
2014-06-01 20:48 GMT+07:00 Marc Mamin m.ma
On Sat, May 31, 2014 at 12:31 AM, Marc Mamin m.ma...@intershop.de wrote:
I have patched intarray with 3 additional functions in order to
count[distinct] event IDs
into arrays, whereas the array position correspond to the integer values.
(mimic column oriented storage)
I didn't look
='{0}'
);
CREATE AGGREGATE iarray_flag(integer) (
SFUNC=iarray_setat,
STYPE=int4[],
INITCOND='{0}'
);
CREATE AGGREGATE iarray_sum(int[]) (
SFUNC=isumv,
STYPE=int[],
INITCOND='{0}'
);
regards,
Marc Mamin
--
Sent via pgsql-hackers mailing list (pgsql
=iarray_addat,
STYPE=int4[],
INITCOND='{0}'
);
CREATE AGGREGATE iarray_flag(integer) (
SFUNC=iarray_setat,
STYPE=int4[],
INITCOND='{0}'
);
CREATE AGGREGATE iarray_sum(int[]) (
SFUNC=isumv,
STYPE=int[],
INITCOND='{0}'
);
regards,
Marc
-rf PG_VERSION (*)
rm -rf pg_xlog
rm -rf postgresql.conf (*)
rm -rf postmaster.log
rm -rf postmaster.opts (*)
(*): could be nice to keep as a reference.
best regards,
Marc Mamin
stopped PID ,
check ntstatus.h for the description of the hexadecimal value
regards,
Marc Mamin
) -
but maybe some enhanced output (only for this resume) can be better:
postgres=# \pset
Output format (format) is aligned.
Border style (border) is 1.
...
+1
Many thanks for taking care of my suggestion.
best regards,
Marc Mamin
,
this is a nice additional feature.
As a user (not a hacker), I would prefer to see the real parameter name instead
of the display name.
e.g.
Border style is 2.
=
border = 2
without this, the user would not know out of the fly which parameter to
modify...
best regards,
Marc Mamin
To avoid redundant
type unknown
DETAIL: Proceeding with relation creation anyway.
Query returned successfully: 2000 rows affected, 9266 ms execution
time.
regards,
Marc Mamin
Von: Tom Lane [t...@sss.pgh.pa.us]
Gesendet: Montag, 27. Mai 2013 16:25
An: Marc Mamin
Cc: 'pgsql-hackers@postgresql.org'
Betreff: Re: [HACKERS] repeated warnings with 9.3 Beta 1 on windows
Marc Mamin m.ma...@intershop.de writes:
while playing with 9.3 Beta 1 on windows, I've
and preferences...
best regards,
Marc Mamin
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Robert Haas
Sent: Freitag, 6. Juli 2012 15:02
To: Dimitri Fontaine
Cc: Tom Lane; Christopher Browne; Pg Hackers
Subject: Re
compatibility, and for cases where the CSV header was
generated by another program (Excel?) so the column names don't match.
4) MAP_HEADER ('column 1'- 'col_1', 'Date' - 'input_date' ...)
to cover the case when column names do not match.
my 2 pences,
Marc Mamin
pg-myhost_3332-20120530_1300.csv
pg-myhost_3332.csv = current
best regards,
Marc Mamin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to help
on this nor to evaluate if this is might be a good Gssoc project.
Just an idea for the case you are looking for another topic.
best regards,
Marc Mamin
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Qi Huang
Sent: Samstag, 24
, the planner chose the worse one,
with severe time differences.
So a naive 'empirical' question:
In case of an inverted index in non lossy situation, shouldn't the
planner also invert its cost assumptions?
best regards,
Marc Mamin
toast impact:
query: select id from table where v
than zlib (-1) and decompresses at 6X.
Regards,
Ken
Hi,
No,
and my concern is more about cost estimation for ts_queries / gin
indexes as for the detoasting issue.
regards,
Marc Mamin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
cosmetic issue as well.
http://archives.postgresql.org/pgsql-bugs/2011-08/msg00113.php
best regards,
Marc Mamin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
imports which may contain
100 Mio rows and require 7 indices on them.
In order to improve import performances, I first do a copy of the active
table, import new data and rebuild the indexes.
Thanks for your great job,
Marc Mamin
This would be great, but I can't C :-(
Marc
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Freitag, 13. Januar 2012 14:12
To: Marc Mamin
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] CLONE TABLE DATA TO new_table
On Fri, Jan 13, 2012 at 5:56
gain compared to the custom type approach.
best regards and Merry Christmas,
Marc Mamin
41 matches
Mail list logo
