--Testing the boundary conditions like in the above example
following should pass.
postgres=# insert into partr_def1 values (1,10);
INSERT 0 1
Thank you,
Rahila Syed
On Mon, Jul 3, 2017 at 8:00 PM, Dilip Kumar wrote:
> On Fri, Jun 30, 2017 at 11:56 AM, Beena Emerson
> wrote:
Hi Beena,
I started testing and reviewing the patch. Can you update the patch as v5
patch does not apply cleanly on master?
Thank you,
Rahila Syed
On Wed, Jun 21, 2017 at 8:43 PM, Dilip Kumar wrote:
> On Wed, Jun 21, 2017 at 8:08 PM, Robert Haas
> wrote:
> > I think somebody sh
I reviewed and tested
0001-Dependency-between-partitioned-table-and-partition_v1.patch
It applies cleanly on master and make check passes.
Following are few comments:
>/*
> * Drop the dependency created by StoreCatalogInheritance1 (CREATE TABLE
> * INHERITS/ALTER TABLE INHERIT -- refclassid will
h you mentioned as a TODO. And run the code
>through pgindent
I will also update the next version with documentation and regression tests
and run pgindent
Thank you,
Rahila Syed
On Fri, May 12, 2017 at 4:33 PM, Beena Emerson
wrote:
>
>
> On Thu, May 11, 2017 at 7:37 PM, Rahila Sye
ded to return false if the node is not DefElem.
Todo:
Add regression tests
Documentation
Thank you,
Rahila Syed
On Fri, May 5, 2017 at 1:30 AM, Jeevan Ladhe
wrote:
> Hi Rahila,
>
> I have started reviewing your latest patch, and here are my initial
> comments:
>
> 1.
> In
ing:
OK. I get it now. If attach partition already supports scanning all the
partitions before attach,
similar support should be provided in the case of adding a partition after
default partition as well.
Thank you,
Rahila Syed
On Wed, May 10, 2017 at 6:42 AM, Amit Langote wrote:
> On 2017/05/10 2:0
>Hi Rahila,
>I am not able add a new partition if default partition is further
partitioned
>with default partition.
>Consider example below:
>postgres=# CREATE TABLE test ( a int, b int, c int) PARTITION BY LIST (a);
>CREATE TABLE
>postgres=# CREATE TABLE test_p1 PARTITION OF test FOR VALUES IN(
+1 for AS DEFAULT syntax if it helps in improving readability specially in
following case
CREATE TABLE p1 PARTITION OF test AS DEFAULT PARTITION BY LIST(a);
Thank you,
Rahila Syed
On Tue, May 9, 2017 at 1:13 AM, Robert Haas wrote:
> On Thu, May 4, 2017 at 4:40 PM, Sven R. Kunze wrote:
>
>I am not able add a new partition if default partition is further
partitioned
>with default partition.
Thanks for reporting. I will fix this.
>pg_restore is failing for default partition, dump file still storing old
syntax of default partition.
Thanks for reporting . I will fix this once the syn
Hello Amul,
Thanks for reporting. Please find attached an updated patch which fixes the
above.
Also, the attached patch includes changes in syntax proposed upthread.
The syntax implemented in this patch is as follows,
CREATE TABLE p11 PARTITION OF p1 DEFAULT;
Thank you,
Rahila Syed
On Thu
Please find attached updated patch with review comments by Robert and
Jeevan implemented.
The newly proposed syntax
CREATE TABLE .. PARTITION OF .. DEFAULT has got most votes on this thread.
If there is no more objection, I will go ahead and include that in the
patch.
Thank you,
Rahila Syed
On
tioning patch. After that I can start with default
partition for range partitioning.
Thank you,
Rahila Syed
ction.
On the other hand if sub partitions of a default partition is to be
prohibited,
an error should be thrown if PARTITION BY is specified after DEFAULT.
Thank you,
Rahila Syed
On Tue, Apr 25, 2017 at 1:46 AM, Robert Haas wrote:
> On Mon, Apr 24, 2017 at 8:14 AM, Ashutosh Bapat
> wr
n overhead, instead we can simply use an array of oids in rd_partdesc.
I think using find_inheritance_children() will take into consideration
concurrent
drop of a partition which the value in rd_partdesc will not.
Thank you,
Rahila Syed
3 shouldn't execute
>in that case, why not just put if (!def_elem) { foreach(cell3, ...) {
>... } } instead of reiterating the ReleaseSysCache in two places?
Fixed in the attached.
I will respond to further comments in following email.
On Thu, Apr 13, 2017 at 12:48 AM, Robert Haas wrot
Hello,
Thanks a lot for testing and reporting this. Please find attached an
updated patch with the fix. The patch also contains a fix
regarding operator used at the time of creating expression as default
partition constraint. This was notified offlist by Amit Langote.
Thank you,
Rahila Syed
On
added partition?
Thank you,
Rahila Syed
On Wed, Apr 5, 2017 at 1:22 PM, Amit Langote
wrote:
> On 2017/04/05 14:41, Rushabh Lathia wrote:
> > I agree about the future plan about the row movement, how that is I am
> > not quite sure at this stage.
> >
> > I was thinking th
Hi,
>However, running your original example, I'm getting this error
Thank you for testing. Please find attached an updated patch which fixes
the above.
Thank you,
Rahila Syed
default_partition_v5.patch
Description: application/download
--
Sent via pgsql-hackers mailing list (pgsql
Hello,
Please find attached an updated patch.
Following has been accomplished in this update:
1. A new partition can be added after default partition if there are no
conflicting rows in default partition.
2. Solved the crash reported earlier.
Thank you,
Rahila Syed
On Tue, Apr 4, 2017 at 6
Thanks for reporting. I have identified the problem and have a fix.
Currently working on allowing
adding a partition after default partition if the default partition does
not have any conflicting rows.
Will update the patch with both of these.
Thank you,
Rahila Syed
On Mon, Mar 27, 2017 at 12:10
r_list().
Have moved the check inside get_qual_for_partbound() as needed to do some
operations
before calling get_qual_for_list() for default partitions.
Thank you,
Rahila Syed
On Tue, Mar 21, 2017 at 11:36 AM, Rushabh Lathia
wrote:
> I picked this for review and noticed that patch is no
patch by tomorrow.
Thank you,
Rahila Syed
On Mon, Mar 13, 2017 at 5:42 AM, Robert Haas wrote:
> On Fri, Mar 10, 2017 at 2:17 PM, Peter Eisentraut
> wrote:
> > On 3/2/17 21:40, Robert Haas wrote:
> >> On the point mentioned above, I
> >> don't think adding a partit
ll leave this decision to the committer.
Thank you,
Rahila Syed
On Wed, Mar 15, 2017 at 1:03 PM, Rushabh Lathia
wrote:
> Thanks Rahila for reviewing this patch.
>
> On Tue, Mar 14, 2017 at 8:13 PM, Rahila Syed
> wrote:
>
>> Hello,
>>
>> I applied an
in relation to creating dsm segments.
write_auto_conf_file()- This is called when updated configuration
parameters are
written to a temp file.
Thank you,
Rahila Syed
On Wed, Mar 8, 2017 at 4:50 PM, Rushabh Lathia
wrote:
>
>
> On Wed, Mar 8, 2017 at
tition. One is to
move the relevant tuples from default to the new partition or like you
suggest keep monitoring the default partition until user moves the rows out
of the default.
Thank you,
Rahila Syed
On Tue, Mar 7, 2017 at 10:00 PM, Keith Fiske wrote:
> On Thu, Mar 2, 2017 at 9:40 PM, Robert
proposal.
https://www.postgresql.org/message-id/CAJ3gD9do9o2ccQ7j7+tSgiE1REY65XRiMb=
yjo3u3qhyp8e...@mail.gmail.com
I am adding it to the current commitfest with the status Waiting on Author
as I will submit an updated patch with above ToDos.
Kindly give your suggestions.
Thank you,
Rahila Syed
y_scan in the above condition. IIUC,
index->amcanparallel is necessary for
parallel index scan to be chosen. We cannot chose parallel index only scan
if index_only_scan is happening
without worrying about index->amcanparallel value. So OR-ing
index->amcanparallel with index_only_scan is probably not
_keys() it advances latest scan which is marked by
btscan->btps_arrayKeyCount only when latest scan
has ended by checking if(btps_pageStatus == BTPARALLEL_DONE) in
_bt_advance_array_keys(). Otherwise, the worker just
advances its local so->arrayKeyCount.
I hope this provides some clarification.
Thank yo
st index pages will give a better estimate of work to be
done
in parallel. As the amount of work/number of pages divided amongst workers
is irrespective of
the number of heap pages scanned.
Thank you,
Rahila Syed
On Mon, Jan 30, 2017 at 2:52 PM, Amit Kapila
wrote:
> On Sat, Jan 28, 2
r("cannot set AUTOCOMMIT to %s when inside a
transaction\n", newval);
>+ }
The above change in autocommit behaviour needs to be documented.
Thank you,
Rahila Syed
On Wed, Jan 25, 2017 at 5:48 PM, Rahila Syed wrote:
> Hello,
>
> The patch works fine on applying on lates
Hello,
The patch works fine on applying on latest master branch and testing it for
various variables as listed in PsqlSettings struct.
I will post further comments on patch soon.
Thank you,
Rahila Syed
On Wed, Jan 25, 2017 at 1:33 AM, Tom Lane wrote:
> "Daniel Verite" writes:
lowing in _bt_readnextpage(),
if (blkno == P_NONE || !so->currPos.moreRight)
{
_bt_parallel_done(scan);
BTScanPosInvalidate(so->currPos);
return false;
}
So to keep it consistent with the existing code, the che
orkers Planned: 4
! -> Parallel Index Only Scan using tenk1_unique1 on tenk1
! (5 rows)
IIUC, parallel operation being performed here is fine as parallel
restricted function occurs above Gather node
and just the expected output needs to be changed.
Thank you,
Rahila Syed
regress
ition fixes the particular case of CREATE VIEW with literal columns
by coercing unknown to text only in this particular case.
Are you suggesting extending the patch to include coercing from unknown to
text for all possible cases where a column of unknown type is being created?
Thank you,
Rahila Sy
ment above the function can be modified as follows,
+ /*
+ * True indicates that the block number returned is either valid including
P_NONE
+ * and scan is continued or block number is invalid and scan has just
+ * begun.
Thank you,
Rahila Syed
On Thu, Dec 22, 2016 at 9:49 AM, Amit Ka
adding this patch to CF 2017-01
Thank you,
Rahila Syed
unknown_view_column_to_text_v1.patch
Description: application/download
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
f'::text AS a;
This allows following queries to run successfully which wasn't the case
earlier.
postgres=# select a from v UNION select a from v1;
a
-
abc
def
(2 rows)
AND
postgres=# select * from v order by 1;
a
-----
abc
(1 row)
Kindly give your opinion.
Thank you,
Rah
pg_strcasecmp(value, "auto") == 0)
popt->topt.expanded = 2;
else if (value)
- popt->topt.expanded = ParseVariableBool(value, param);
+ {
+ boolvalid;
+ boolnewval = ParseVariableBool(value, param, &valid);
+ if (va
n is InvalidOid.
So if we ensure assignment of a valid collation when the left and the right
columns/inputs
are UNKNOWN, the above can be resolved.
Attached WIP patch does that. Kindly let me know your opinion.
Thank you,
Rahila Syed
invalid_collation_error.patch
Description: applicatio
want to
>ignore the return value here. I expect some compilers might
>complain under a high level of warnings without this cast, although
>TBH if you ask me, I wouldn't know which compiler with which flags
>exactly.
Thank you for explanation.
Thank you,
Rahila Syed
On Fri, Nov
(NULL); /* ignore return value */
Sorry for my lack of understanding, can you explain why is above change
needed?
Thank you,
Rahila Syed
On Tue, Sep 20, 2016 at 11:16 PM, Daniel Verite
wrote:
> Ashutosh Bapat wrote:
>
> > You may want to add this to the November c
ed on log of number of pages so it will make
even lesser difference.
Thank you,
Rahila Syed
On Tue, Oct 18, 2016 at 8:38 AM, Amit Kapila
wrote:
> On Thu, Oct 13, 2016 at 8:48 AM, Amit Kapila
> wrote:
> > As of now, the driving table for parallel query is accessed by
> >
gt;}
>vacuum_delay_point();
>next_unskippable_block++;
>+ n_skipped++;
>}
>}
Also, instead of incrementing n_skipped everytime, it can be set to
'next_unskippable_block' or 'next_unskippable_block -blkno'
once at the end of the
iableBool(value, param);
^
In file included from settings.h:12:0,
from command.c:50:
variables.h:38:7: note: declared here
bool ParseVariableBool(const char *value, const char *name, bool *valid);
^
Thank you,
Rahila Syed
On Mon, Sep 19, 2016 at 11:21 AM, Ashuto
viour of \set AUTOCOMMIT ON in such
scenario can
be confusing.
Thank you,
Rahila Syed
On Wed, Sep 14, 2016 at 8:06 PM, Tom Lane wrote:
> Rahila Syed writes:
> >> Looking at the other variables hooks, they already emit errors and can
> >> deny the effect of a change corresp
transaction, it will be effective after current transaction
has
ended. Appropriate message will be displayed notifying this to the user and
user need not
rerun the set AUTOCOMMIT command.
Thank you,
Rahila Syed
On Thu, Sep 8, 2016 at 9:55 PM, Daniel Verite
wrote:
> Rahila Syed wrote:
ss of the
command so it is better placed
in exec_command().
Thank you,
Rahila Syed
On Sat, Sep 3, 2016 at 4:39 PM, Daniel Verite
wrote:
> Rushabh Lathia wrote:
>
> > It might happen that SetVariable() can be called from other places in
> > future,
> >
hank you,
Rahila Syed
On Fri, Sep 2, 2016 at 3:17 PM, Rushabh Lathia
wrote:
>
>
> On Fri, Sep 2, 2016 at 1:12 PM, Rahila Syed
> wrote:
>
>> Hello,
>>
>> Thank you for comments.
>>
>> >Above test not throwing psql error, as you used strcmp(newval,&quo
MIT is turned on inside a
transaction. But only when there is an implicit BEGIN as in following case,
postgres=# \set AUTOCOMMIT OFF
postgres=# create table test(i int);
CREATE TABLE
postgres=# \set AUTOCOMMIT ON
\set: Cannot set AUTOCOMMIT to ON inside a transaction, either COMMIT or
ROLLBACK and ret
F
postgres=# create table test(i int);
CREATE TABLE
postgres=# \set AUTOCOMMIT ON
\set: Cannot set AUTOCOMMIT to ON inside a transaction, either COMMIT or
ROLLBACK and retry
postgres=#
Thank you,
Rahila Syed
On Wed, Aug 17, 2016 at 6:31 PM, Robert Haas wrote:
> On Tue, Aug 16, 2016 at 5:25 PM
think should be OK as
it will be notified via ERROR).
So summarizing my view of the discussion on this thread, issuing a psql
error seems to be the best option. I will post a patch regarding this if
there is no objection.
Thank you,
Rahila Syed
user friendliness.
While I agree that issuing an ERROR and rolling back the transaction ranks
higher in safe behaviour, it is not as common (according to instances
stated upthread) as immediately committing any open transaction when
switching back to autocommit.
Thank you,
Rahila Syed
On Sun,
it through ecpg commits the ongoing transaction
when autocommit is set to ON from OFF. Should such behaviour be implemented
for \set AUTOCOMMIT ON as well?
Thank you,
Rahila Syed
>Oops. I forgot to credit you in the commit message. Sorry about that.
:-(
No problem :). Thanks for the commit.
Thank you,
Rahila Syed
try->st_progress_param[i]);
Attached patch fixes this.
Thank you,
Rahila Syed
On Wed, Mar 16, 2016 at 11:30 PM, Robert Haas wrote:
> On Wed, Mar 16, 2016 at 6:44 AM, Rahila Syed
> wrote:
> >>Sorta. Committed after renaming what you called heap blocks vacuumed
> >>back to heap bloc
which appear before final vacuum cycle happens for any remaining dead
tuples which may span few pages if I am not mistaken.
IMO, reporting final count of heap_blks_scanned is correct here, but
reporting final heap_blks_vacuumed can happen after the final VACUUM cycle
for more accuracy.
Thank you,
Rahila Syed
. Though this
function basically updates local structures and sends the count to stat
collector via messages we can have a function which will instead modify the
shared state using the progress API committed recently.
Thank you,
Rahila Syed
to see if it matches any of the dead tuple
tids.
So additional parameters for each index can be,
scanned_index_tuples
total_index_tuples (from pg_class.reltuples entry)
Thank you,
Rahila Syed
[1]. http://www.postgresql.org/message-id/56500356.4070...@bluetreble.com
should
it.
Yes. This was incorrectly added initially by referring to similar
pgstat_report interface functions.
Thank you,
Rahila Syed
On Thu, Jan 28, 2016 at 2:27 AM, Robert Haas wrote:
> On Tue, Jan 26, 2016 at 11:37 PM, Vinayak Pokale
> wrote:
> > Hi,
> >
> >
Is there still some way to add it to the commitfest 2016-01? As
this feature has received lot of feedback in previous commitfest , adding
it to this commitfest will surely help in progressing it in order to make
it ready for PostgreSQL 9.6.
Thank you,
Rahila Syed
On Mon, Dec 28, 2015 at 6:01 AM, A
h include name change of
activity flag, reporting only changed parameters to shared memory,
ACTIVITY_IS_VACUUM flag being set unnecessarily for ANALYZE and FULL
commands ,documentation for new view.
Also, finer grain reporting from indexes and heap truncate phase is yet to
be incorporated into the
Hello Michael,
I am planning to continue contributing to this feature in any way be it by
reviewing the patch or making one. Though I haven't been able to reply to
the comments or post an updated patch lately. I plan to do that soon.
Thank you,
Rahila
On Thu, Nov 19, 2015 at 1:09 PM, Michael Paq
>This doesn't seem to compile
Oh. It compiled successfully when applied on HEAD on my machine. Anyways,
the OID is changed to 3309 in the attached patch. 3308 / 3309 both are part
of OIDs in unused OID list.
Thank you,
Rahila Syed
Vacuum_progress_checker_v2.patch
Description: Bin
Hello,
On Jul 16, 2015 1:48 AM, "Rahila Syed" wrote:
>
> Hello,
>
> Please find attached updated patch >with an interface to calculate
command progress in pgstat.c. This interface currently
implements VACUUM progress tracking .
I have added this patch to CommitFest
ata is
>free-style data which is stored by each backend as it like.
If I understand your point correctly, I think you are missing following,
The amount of additional information for each command can be different. We
may need an array of text and numeric data to represent more additional
informatio
ress message.
Phase 3. 1 integer counter: heap pages vacuumed.
This structure can be accessed by statistics collector to display progress
via new view.
Thank you,
Rahila Syed
be provided by summing
up heap pages scanned, index pages scanned against total heap pages, total
index pages * number of index scans.
Thank you,
Rahila Syed
d by single dead
tuple)/m_w_m,1)
This estimates index_scans = 1 if n_dead_tuples = 0 assuming lazy scan heap
is likely to find some dead_tuples.
If n_dead_tuples is non zero the above estimate gives a lower bound on
number of index scans possible.
Thank you,
Rahila Syed
of now .
Thank you,
Rahila Syed.
Vacuum_progress_checker_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
thread,
http://www.postgresql.org/message-id/AANLkTi=TcuMA38oGUKX9p5WVPpY+M3L0XUp7=plt+...@mail.gmail.com
Thank you,
Rahila Syed
On Tue, Jun 30, 2015 at 1:22 PM, Pavel Stehule
wrote:
> Hi
>
> 2015-06-30 9:37 GMT+02:00 Rahila Syed :
>
>> Hello Hackers,
>>
>> Following is
w for
VACUUM.
-Rahila Syed
On Tue, Jun 30, 2015 at 2:02 PM, Simon Riggs wrote:
> On 30 June 2015 at 08:52, Pavel Stehule wrote:
>
>
>> I though about the possibilities of progress visualization - and one
>> possibility is one or two special column in pg_stat_act
Hello,
>I have some minor comments
The comments have been implemented in the attached patch.
>I think that extra parenthesis should be used for the first expression
>with BKPIMAGE_HAS_HOLE.
Parenthesis have been added to improve code readability.
Thank you,
Rahila Syed
On Mon, Mar 9
and block references. Chunk ID of
block references can contain information about presence of data, image ,
hole and compression.
Chunk ID for main data fragments remains as it is . This approach provides
for readability and extensibility.
Thank you,
Rahila Syed
On Mon, Mar 2, 2015 at 3:43 PM, Fuji
10
+#define XLR_CHUNK_BLOCK_HAS_IMAGE 0x04
+#define XLR_CHUNK_BLOCK_HAS_DATA 0x08
XLR_CHUNK_BLOCK_REFERENCE denotes chunk ID of block references.
XLR_CHUNK_BLOCK_HAS_IMAGE is a replacement of BKPBLOCK_HAS_IMAGE
and XLR_CHUNK_BLOCK_HAS DATA a replacement of BKPBLOCK_HAS_DATA.
Thank you,
Rahila Sye
nearly same as before. There is some difference in WAL
between HEAD and HEAD+patch+compression OFF. This difference corresponds to
1 byte increase with each block reference of xlog record.
Thank you,
Rahila Syed
On Wed, Feb 18, 2015 at 7:53 PM, Syed, Rahila
wrote:
> Hello,
>
> &g
the tests to gather
above data.
Thank you,
Rahila Syed
--
View this message in context:
http://postgresql.nabble.com/Compression-of-full-page-writes-tp5769039p5833389.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-
Processor E5-2650 (2 GHz, 8C/16T, 20 MB) * 2 nos
RAM: 32GB
Disk : HDD 450GB 10K Hot Plug 2.5-inch SAS HDD * 8 nos
1 x 450 GB SAS HDD, 2.5-inch, 6Gb/s, 10,000 rpm
Thank you,
Rahila Syed
--
View this message in context:
http://postgresql.nabble.com/Compression-of-full-page-writes
as original length is not deducible from compressed data and rather
stored in header.
Thank you,
Rahila Syed
--
View this message in context:
http://postgresql.nabble.com/Compression-of-full-page-writes-tp5769039p5833025.html
Sent from the PostgreSQL - hackers mailing list archive at Nabbl
HDD, 2.5-inch, 6Gb/s, 10,000 rpm
Thank you,
Rahila Syed
/message-id/ca+tgmoaznbuwnls4bpwyqgqteeznoavy7kwdbm0a2-tbarn...@mail.gmail.com
Thank you,
Rahila Syed
On Thu, Dec 18, 2014 at 1:57 PM, Fujii Masao wrote:
>
> On Thu, Dec 18, 2014 at 2:21 PM, Michael Paquier
> wrote:
> >
> >
> > On Wed, Dec 17, 2014 at 11:33 PM, Rahila Syed
> > wrote:
&
ck is
considered
+* as incompressible, complete the block header information as
if
+* nothing happened.
As hole is no longer being compressed, this needs to be changed.
Thank you,
Rahila Syed
On Tue, Dec 16, 2014 at 10:04 PM, Michael Paquier wrote:
>
>
>
>
ockHeader struct itself.
Thank you,
Rahila Syed
correct_comment_typo_XLogRecordBlockHeader.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ad of flushing WAL records to disk in servers with heavy
write operations. So yes improving the performance by saving write volume
is a part of the requirement.
Thank you,
Rahila Syed
On Fri, Dec 12, 2014 at 7:48 PM, Bruce Momjian wrote:
>
> On Fri, Dec 12, 2014 at 08:27:59AM -0500, Rober
t
takes little less than double CPU time to compress.
However , the total time taken to run 25 transactions for each of the
scenario is as follows,
compression = 'on' : 1838 secs
= 'off' : 1701 secs
Different is around 140 secs.
Thank you,
Rahila Sy
igh.
Server specifications:
Processors:Intel® Xeon ® Processor E5-2650 (2 GHz, 8C/16T, 20 MB) * 2 nos
RAM: 32GB
Disk : HDD 450GB 10K Hot Plug 2.5-inch SAS HDD * 8 nos
1 x 450 GB SAS HDD, 2.5-inch, 6Gb/s, 10,000 rpm
Thank you,
Rahila Syed
On Fri, Dec 5, 2014 at 10:38 PM, Robert Haas
ssed as well as uncompressed blocks.
As you already mentioned, this will need compressing images with hole but
we can MemSet hole to 0 in order to make compression of hole less
expensive and effective.
Thank you,
Rahila Syed
On Sat, Dec 6, 2014 at 7:37 PM, Michael Paquier
wrote:
>
> O
- record->blocks[block_id].compress_len;
IIUC, fpi_len in case of compressed block image should be
fpi_len = record->blocks[block_id].compress_len;
Thank you,
Rahila Syed
--
View this message in context:
http://postgresql.nabble.com/Compression-of-full-page-writes-tp5769039p58294
com
The above tests were performed on machine with configuration as follows
Server specifications:
Processors:Intel® Xeon ® Processor E5-2650 (2 GHz, 8C/16T, 20 MB) * 2 nos
RAM: 32GB
Disk : HDD 450GB 10K Hot Plug 2.5-inch SAS HDD * 8 nos
1 x 450 GB SAS HDD, 2.5-inch, 6Gb/s, 10,000 rpm
IIUC, forcibly written fpws are not exposed to user , so is it worthwhile to
add a GUC similar to full_page_writes in order to control a feature which is
unexposed to user in first place?
If full page writes is set ‘off’ by user, user probably cannot afford the
overhead involved in writing large p
Access as per earlier discussion.
I have attached the changes separately as changes.patch.
Thank you,
Rahila Syed
changes.patch
Description: Binary data
0002-Support-compression-for-full-page-writes-in-WAL.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hack
at it is an attribute of
all the records when it is only an attribute of records with backup blocks
or the attribute of backup blocks.
The current approach is adopted with this thought.
Regards,
Rahila Syed
--
View this message in context:
http://postgresql.nabble.com/Compressio
. This is
done in order to avoid adding compression information in WAL record header.
Memory allocation on SIGHUP in autovacuum is remaining. Working on it.
Thank you,
Rahila Syed
On Tue, Oct 28, 2014 at 8:51 PM, Rahila Syed
wrote:
>
> >>>Do we release the buffers for compr
ill be rectified.
>Which would prevent the recovery at all, so PANIC should
>happen in that case?
IIUC, instead of reporting PANIC , palloc can be used to allocate memory
for uncompressedPages at the time of recovery which will throw ERROR and
abort startup process in case of failur
One
> thing worthy of note is that I don't think you currently can
> "legally" check fullPageWrites == FULL_PAGE_WRITES_ON when calling it
> only during startup as fullPageWrites can be changed at runtime
In the attached patch, this check is also added in PostgresMain on SIGHUP
em handling is done in order to
proceed without compression of FPW in case sufficient memory is not
available for compression.
Thank you,
Rahila Syed
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Compression-of-full-page-writes-tp5769039p5822391.html
Sent from the Postg
65.36
Compress(pglz) 6518.681072.34
59.66
Off 501.04
1135.1756.34
The results show around 30 percent decrease in WAL volume due to
compression of
Thank you,
Rahila Syed
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Compression-of-full-page-writes-tp5769039p5819659.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
Hello,
>Maybe. Let's get the basic patch done first; then we can argue about that
Please find attached patch to compress FPW using pglz compression.
All backup blocks in WAL record are compressed at once before inserting it
into WAL buffers . Full_page_writes GUC has been modified to accept thr
>I will repeat the above tests with high load on CPU and using the benchmark
given by Fujii-san and post the results.
Average % of CPU usage at user level for each of the compression algorithm
are as follows.
CompressionMultipleSingle
Off81.1338
gt; Em 26/08/2014 09:16, "Fujii Masao" escreveu:
>
> >
> > On Tue, Aug 19, 2014 at 6:37 PM, Rahila Syed
> wrote:
> > > Hello,
> > > Thank you for comments.
> > >
> > >>Could you tell me where the patch for "single
1 - 100 of 111 matches
Mail list logo
