> Can't really blame Windows on that. On Windows, we don't require that the
> encoding and LC_CTYPE's charset match. The OP used UTF-8 encoding in the
> server, but LC_CTYPE="English_United Kingdom.1252", ie. LC_CTYPE implies
> WIN1252 encoding. We allow that and it generally works on Windows
> bec
No matter how I try to redesign the schema the indexes consume large amount of
memory,
About 8KB per index.
Is there a way to invalidated this cache?
Is there a way to limit the amount of memory and use some kind of LRU/LFU
algorithm to clean old cache?
-Original Message-
From: Atri S
On Tue, Jun 4, 2013 at 3:57 AM, Robert Haas wrote:
> On Thu, May 30, 2013 at 1:39 AM, Michael Paquier
> wrote:
> > +1.
>
> Here's a more serious patch for MVCC catalog access. This one
> involves more data copying than the last one, I think, because the
> previous version did not register the s
Joe Conway writes:
> I was surprised by a couple of things looking at this code. First,
> getRules() is written differently than other table subsidiary objects'
> get functions. Secondly, I would have expected
> getExtensionMembership() to be recursive -- instead it looks to only
> go one level de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/02/2013 03:10 PM, Dimitri Fontaine wrote:
> Tom Lane writes:
>>> Actually, I believe the answer is just that getSchemaData() is
>>> doing things in the wrong order:
Indeed Tom, as usual, seems to have the best correct answer :-)
New patch atta
On 06/03/2013 09:30 PM, Peter Eisentraut wrote:
I suppose we'll be branching off 9.3 in a few weeks. That event always
creates a service gap in the build farm and similar services, and a race
in the NLS service to get everything adjusted to the new branch.
The buildfarm has had a mechanism f
I suppose we'll be branching off 9.3 in a few weeks. That event always
creates a service gap in the build farm and similar services, and a race
in the NLS service to get everything adjusted to the new branch.
It seems to me we could already now create a git symbolic-ref named
REL9_3_STABLE that p
On Sun, Jun 02, 2013 at 10:45:21AM +0100, Simon Riggs wrote:
> For clarity the 4 problems are
> 1. SQL execution overhead
> 2. Memory usage
> 3. Memory scrolling
> 4. Locking overhead, specifically FPWs and WAL records from FK checks
> probably in that order or thereabouts.
>
> The above is why I
On Mon, May 13, 2013 at 3:22 PM, Peter Geoghegan wrote:
> Attached patch renders all "loaded library..." messages DEBUG1,
> regardless of whether local_preload_libraries or
> shared_preload_libraries is involved, and regardless of EXEC_BACKEND.
Can someone take a look at this, please? I'd rather
> All that has pretty significantly changed - and imo improved! - in the
> last year or so of kernel development. Unfortunately it will take a
> while till we commonly see those kernels being used :(
... after being completely broken for 3.2 through 3.5.
We're actually using 3.9 in production on
On 2013-06-03 16:41:32 -0700, Peter Geoghegan wrote:
> On Mon, Jun 3, 2013 at 3:16 PM, Kevin Grittner wrote:
> >> But it seems like the kernel is disposed to cache large amounts
> >> of dirty data for an unbounded period of time even if the I/O
> >> system is completely idle,
> >
> > It's not unbo
On 06/04/2013 05:27 AM, Peter Geoghegan wrote:
> On Mon, Jun 3, 2013 at 5:03 AM, Craig Ringer wrote:
>> I've seen cases on Stack Overflow and elsewhere in which disk merge
>> sorts perform vastly better than in-memory quicksort, so the user
>> benefited from greatly *lowering* work_mem.
> I've hea
On Mon, Jun 3, 2013 at 3:16 PM, Kevin Grittner wrote:
>> But it seems like the kernel is disposed to cache large amounts
>> of dirty data for an unbounded period of time even if the I/O
>> system is completely idle,
>
> It's not unbounded time. Last I heard, the default was 30 seconds.
I'm prett
Robert Haas wrote:
> Martijn van Oosterhout wrote:
>> On Mon, Jun 03, 2013 at 11:27:57AM +0300, Ants Aasma wrote:
>>> It could be related to the OS. I have no evidence for or against, but
>>> it's possible that OS write-out routines defeat the careful cost based
>>> throttling that PostgreSQL do
On Mon, Jun 3, 2013 at 3:48 PM, Martijn van Oosterhout
wrote:
> On Mon, Jun 03, 2013 at 11:27:57AM +0300, Ants Aasma wrote:
>> > I can't rule that out. Personally, I've always attributed it to the
>> > fact that it's (a) long and (b) I/O-intensive. But it's not
>> > impossible there could also b
On Mon, Jun 3, 2013 at 5:03 AM, Craig Ringer wrote:
> I've seen cases on Stack Overflow and elsewhere in which disk merge
> sorts perform vastly better than in-memory quicksort, so the user
> benefited from greatly *lowering* work_mem.
I've heard of that happening on Oracle, when the external sor
On Mon, Jun 3, 2013 at 2:56 PM, Josh Berkus wrote:
> Really? I though vacuum held onto its locks until it reached
> vacuum_cost. If it doesn't, then maybe we should adjust the default for
> vacuum_cost_limit upwards.
That would be completely insane.
Or in other words, no, it doesn't do anythin
javadi wrote:
> I want to find some architectural information about the storage
> subsystem of PostgreSQL especially the modulus which are responsible to
> loading data from disk to the Shared Buffer. I cannot find any
> structured and useful information on web.
>
> Would you please help me to f
On Sat, Jun 1, 2013 at 02:11:13PM +0430, javadi wrote:
> Hi
>
> I want to find some architectural information about the storage
> subsystem of PostgreSQL especially the modulus which are responsible to
> loading data from disk to the Shared Buffer. I cannot find any
> structured and useful infor
On Mon, Jun 03, 2013 at 11:27:57AM +0300, Ants Aasma wrote:
> > I can't rule that out. Personally, I've always attributed it to the
> > fact that it's (a) long and (b) I/O-intensive. But it's not
> > impossible there could also be bugs lurking.
>
> It could be related to the OS. I have no eviden
Hi
I want to find some architectural information about the storage
subsystem of PostgreSQL especially the modulus which are responsible to
loading data from disk to the Shared Buffer. I cannot find any
structured and useful information on web.
Would you please help me to find such information.
On 3 June 2013 19:41, Jim Nasby wrote:
> On 6/2/13 4:45 AM, Simon Riggs wrote:
>>>
>>> >Will this add too much cost where it doesn't help? I don't know what to
>>> >predict there. There's the obvious case of trivial transactions with no
>>> > more
>>> >than one referential integrity check per FK
On 06/03/2013 11:12 AM, Andres Freund wrote:
> On 2013-06-03 11:00:38 -0700, Josh Berkus wrote:
>>
Also, locking while it does its work.
>>>
>>> Eh?
>>
>> Even if we're doing lazy vacuum, we have to lock a few pages at a time
>> of each table. This does result in response time delays on the c
On 03.06.2013 21:28, Tom Lane wrote:
Heikki Linnakangas writes:
He *is* using UTF-8. Or trying to, anyway :-). The downcasing in the
backend is supposed to leave bytes with the high-bit set alone, ie. in
UTF-8 encoding, it's supposed to leave ä and ß alone.
Well, actually, downcase_truncate
On 06/03/2013 02:28 PM, Tom Lane wrote:
. I wonder though if we couldn't just fix this code to not do anything
to high-bit-set bytes in multibyte encodings.
That's exactly what I suggested back in November.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On 6/2/13 4:45 AM, Simon Riggs wrote:
>Will this add too much cost where it doesn't help? I don't know what to
>predict there. There's the obvious case of trivial transactions with no more
>than one referential integrity check per FK, but there's also the case of a
>transaction with many FK che
Yes, that is currently used for REFRESH, and will be used to drive the
incremental maintenance when that is added. Without it, CREATE
MATERIALIZED VIEW wouldn't be different from CREATE TABLE AS.
A materialized view is pretty much like a view, but with the results
materialized.
-Kevin
On Mon,
Heikki Linnakangas writes:
> He *is* using UTF-8. Or trying to, anyway :-). The downcasing in the
> backend is supposed to leave bytes with the high-bit set alone, ie. in
> UTF-8 encoding, it's supposed to leave ä and à alone.
Well, actually, downcase_truncate_identifier() is doing this:
On 2013-06-03 11:00:38 -0700, Josh Berkus wrote:
>
> >> Also, locking while it does its work.
> >
> > Eh?
>
> Even if we're doing lazy vacuum, we have to lock a few pages at a time
> of each table. This does result in response time delays on the current
> workload, which can be quite bad if it'
>> Also, locking while it does its work.
>
> Eh?
Even if we're doing lazy vacuum, we have to lock a few pages at a time
of each table. This does result in response time delays on the current
workload, which can be quite bad if it's a highly contended table already.
--
Josh Berkus
PostgreSQL E
> hm, in that case, wouldn't adding 48gb of physical memory have
> approximately the same effect? or is something else going on?
imho, adding 48gb would have no effects.
server already has 376GB memory and still has a lot of unused GB.
let me repeat, we added 80GB for files cache by decreasing b
On Mon, Jun 3, 2013 at 1:28 PM, Josh Berkus wrote:
> Does anti-wraparound vacuum (AWAV) write synchronously? If so, there's
> a potential whole world of hurt there.
Not any moreso than anything else ... although it probably does a very
high percentage of FPIs, which might lead to lots of checkpo
On 06/03/2013 12:22 PM, Heikki Linnakangas wrote:
On 03.06.2013 18:27, k...@rice.edu wrote:
On Mon, Jun 03, 2013 at 04:09:29PM +0100, Martin Schäfer wrote:
If I change the strCreate query and add double quotes around the
column
name, then the problem disappears. But the original name is alr
Jeff,
> Do we know why anti-wraparound uses so many resources in the first place?
> The default settings seem to be quite conservative to me, even for a
> system that has only a single 5400 rpm hdd (and even more so for any real
> production system that would be used for a many-GB database).
>
>
> I agree with all that. I don't have any data either, but I agree that
> AFAICT it seems to mostly be a problem for large (terabyte-scale)
> databases, or ones that are dreadfully short of I/O bandwidth. AWS,
> I'm looking at you.
Well, at this point, numerically I'd bet that more than 50% of
On Mon, Jun 3, 2013 at 11:08 AM, Миша Тюрин wrote:
> Hi all hackers again!
> Since i had got this topic there many test was done by our team and many
> papers was seen. And then I noticed that os_page_replacement_algorithm with
> CLOCK and others features
>
> might * interfere / overlap * with/o
On 03.06.2013 18:27, k...@rice.edu wrote:
On Mon, Jun 03, 2013 at 04:09:29PM +0100, Martin Schäfer wrote:
If I change the strCreate query and add double quotes around the column
name, then the problem disappears. But the original name is already in
lowercase, so I think it should also work wi
On Jun 3, 2013, at 7:31 AM, Tom Lane wrote:
> Hah. That leads to
> http://perl5.git.perl.org/perl.git/commitdiff/451f421
> in which it's said "What happens is that eval tacks "\n;" on to the end
> of the string if it does not already end with a semicolon."
>
> So we could likely hide the cross-
On Mon, Jun 3, 2013 at 3:59 PM, Kevin Grittner wrote:
> Dave Page wrote:
>> Kevin Grittner wrote:
>>> Dave Page wrote:
>
In playing with materialized views, I noticed that they still
seem to have an _RETURN rule implicitly created like a regular
view.
>
>>> A materialized view is
On Mon, Jun 03, 2013 at 04:09:29PM +0100, Martin Schäfer wrote:
>
> > > If I change the strCreate query and add double quotes around the column
> > name, then the problem disappears. But the original name is already in
> > lowercase, so I think it should also work without quoting the column name.
Stephen Frost escribió:
> Just to wrap this up- I wanted to say thanks to both you (Bruce) and
> to Andrew for making pgindent work and the documentation / instructions
> easy to follow. In the past, pgindent has always seemed to be a black
> art, where it was difficult to get consistent results
> -Original Message-
> From: k...@rice.edu [mailto:k...@rice.edu]
> Sent: 03 June 2013 16:48
> To: Martin Schäfer
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] UTF-8 encoding problem w/ libpq
>
> On Mon, Jun 03, 2013 at 03:40:14PM +0100, Martin Schäfer wrote:
> > I try to c
Dave Page wrote:
> Kevin Grittner wrote:
>> Dave Page wrote:
>>> In playing with materialized views, I noticed that they still
>>> seem to have an _RETURN rule implicitly created like a regular
>>> view.
>> A materialized view is pretty much like a view, but with the
>> results materialized.
>
Hi Stephen,
I have some basic question - How do I add this flags CATCACHE_STATS and
CATCACHE_FORCE_RELEASE when building postgresql?
I added it to src/Makefile.global in this line:
CPPFLAGS = -D_GNU_SOURCE -DCATCACHE_STATS -DCATCACHE_FORCE_RELEASE
And changed log level to debug2, but it doesn
On Mon, Jun 03, 2013 at 03:40:14PM +0100, Martin Schäfer wrote:
> I try to create database columns with umlauts, using the UTF8 client
> encoding. However, the server seems to mess up the column names. In
> particular, it seems to perform a lowercase operation on each byte of the
> UTF-8 multi-b
I try to create database columns with umlauts, using the UTF8 client encoding.
However, the server seems to mess up the column names. In particular, it seems
to perform a lowercase operation on each byte of the UTF-8 multi-byte sequence.
Here is my code:
const wchar_t *strName = L"id_äß";
Kaare Rasmussen writes:
> That page is not updated, it seems. In this list
> https://metacpan.org/module/RJBS/perl-5.18.0/pod/perldelta.pod
> is mentioned "Line numbers at the end of a string eval are no longer off
> by one. [perl #114658]"
Hah. That leads to
http://perl5.git.perl.org/perl.git/
On 03.06.2013 17:18, Tom Lane wrote:
Heikki Linnakangas writes:
In the interest of getting the release out, I've reverted commit
a475c603. We'll probably want to do something more elegant in the
future, but this will do for now.
That may be the best short-term answer, but I see no such revert
Heikki Linnakangas writes:
> In the interest of getting the release out, I've reverted commit
> a475c603. We'll probably want to do something more elegant in the
> future, but this will do for now.
That may be the best short-term answer, but I see no such revert
in the repo ...
Dave Page writes:
> On Mon, Jun 3, 2013 at 1:06 PM, Kevin Grittner
> wrote:
>> A materialized view is pretty much like a view, but with the results
>> materialized.
> Yeah, I get that, but what is confusing is that this now seems to be a
> special kind of relation where there is an ON SELECT DO
On 2013-06-02 11:44:04 -0700, Jeff Janes wrote:
> Do we know why anti-wraparound uses so many resources in the first place?
> The default settings seem to be quite conservative to me, even for a
> system that has only a single 5400 rpm hdd (and even more so for any real
> production system that wo
Craig Ringer wrote:
> On 06/02/2013 05:56 AM, Robert Haas wrote:
>> I agree with all that. I don't have any data either, but I agree that
>> AFAICT it seems to mostly be a problem for large (terabyte-scale)
>> databases, or ones that are dreadfully short of I/O bandwidth. AWS,
>> I'm looking at
* Clark C. Evans (c...@clarkevans.com) wrote:
> Yes, if we had per-database roles, it would work. However, I don't
> think it's necessary. We've already got role permissions specific to
> a database; so we're most of the way there.
PG has two sets of catalogs, per-databases ones and 'shared' o
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, May 31, 2013 at 03:51:30PM -0400, Andrew Dunstan wrote:
> > I spent quite a lot of time trying to make the tool behave the same
> > as the old script.
>
> Yes, and I believe we tested running the Perl version to make sure it
> was the same, so th
* Thom Brown (t...@linux.com) wrote:
> Oh, if you're in the mood for typo-correction...
Done, thanks.
I wouldn't be against material improvements to the comments in some of
the code that's being fixed for typos either, by the way.. Starting
with actually *having* some, in some places.
T
On Mon, Jun 3, 2013 at 1:06 PM, Kevin Grittner
wrote:
> Yes, that is currently used for REFRESH, and will be used to drive the
> incremental maintenance when that is added. Without it, CREATE MATERIALIZED
> VIEW wouldn't be different from CREATE TABLE AS.
OK.
> A materialized view is pretty muc
On 06/02/2013 05:56 AM, Robert Haas wrote:
> On Sat, Jun 1, 2013 at 1:49 PM, Simon Riggs wrote:
>> On 30 May 2013 19:48, Josh Berkus wrote:
>>
>>> There's currently some great ideas bouncing around about eliminating the
>>> overhead associated with FREEZE. However, I wanted to take a step back
>
Hi
In playing with materialized views, I noticed that they still seem to
have an _RETURN rule implicitly created like a regular view. This
doesn't seem right to me - is there a reason?
viper:~ dpage$ /usr/local/pgsql-9.3/bin/psql -p 5433 -U postgres
psql (9.3beta1)
Type "help" for help.
postgres
On Mon, Jun 3, 2013 at 1:20 AM, Robert Haas wrote:
> On Sun, Jun 2, 2013 at 2:44 PM, Jeff Janes wrote:
>> Do we know why anti-wraparound uses so many resources in the first place?
>> The default settings seem to be quite conservative to me, even for a system
>> that has only a single 5400 rpm hdd
We've almost cleared the open items list, and I'm not aware of any other
unfixed issues in 9.3beta1. Could we make a beta2 release soon? There
have been a bunch of recovery-related fixes since beta1, it would be
nice to get those fixes in the hands of testers.
- Heikki
--
Sent via pgsql-hack
On 14.05.2013 15:35, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
I don't disagree, but how is that relevant for fixing the issue at hand?
We still need to fix restores that currently target the wrong schema in
a backward compatible manner?
On this, I agree w/ Tom that
61 matches
Mail list logo
