17.09.11 23:01, Stefan Keller написав(ла):
* more... ?
What I miss from my DB2 UDB days are buffer pools. In PostgreSQL terms
this would be part of shared buffers dedicated to a relation or a set of
relations. When you have a big DB (not fitting in memory) you also
usually want some small
Stefan Keller, 17.09.2011 22:01:
I'm also interested in such proposals or ideas!
Here's some list of topics:
* Time in PostgreSQL
* Fast Bulk Data Inserting in PostgreSQL with Unlogged tables
I don't understand these two items. Postgres does have a time data type and it
has unlogged tables
On Sun, Sep 18, 2011 at 9:31 PM, Stefan Keller sfkel...@gmail.com wrote:
I'm simply referring to literature (like the intro Ramakrishnan Gehrke).
I just know that Oracle an Mysql actually do have them too and use it
without those current implementation specific restrictions in
Postgres.
2011/9/19 Vitalii Tymchyshyn tiv...@gmail.com:
17.09.11 23:01, Stefan Keller написав(ла):
* more... ?
What I miss from my DB2 UDB days are buffer pools. In PostgreSQL terms this
would be part of shared buffers dedicated to a relation or a set of
relations. When you have a big DB (not
Robert Klemme, 19.09.2011 13:13:
On Sun, Sep 18, 2011 at 9:31 PM, Stefan Kellersfkel...@gmail.com wrote:
I'm simply referring to literature (like the intro Ramakrishnan Gehrke).
I just know that Oracle an Mysql actually do have them too and use it
without those current implementation specific
Hello.
I did read and AFAIR sometimes responded on this long discussions. The
main point for me is that many DBAs dont want to have even more random
plans with postgresql knowing what's in memory now and using this
information directly in runtime. I also think this point is valid.
What I
On 17/09/2011 22:01, Stefan Keller wrote:
2011/9/17 Tomas Vondra t...@fuzzy.cz wrote:
(...)
We've been asked by a local university for PostgreSQL-related topics of
theses and seminary works
I'm also interested in such proposals or ideas!
Here's some list of topics:
* Adding WAL-support
On Sun, Sep 18, 2011 at 9:59 AM, Stefan Keller sfkel...@gmail.com wrote:
Merlin and Jeff,
General remark again:It's hard for me to imagine that btree is
superior for all the issues mentioned before. I still believe in hash
index for primary keys and certain unique constraints where you need
On Mon, Sep 19, 2011 at 4:04 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Sun, Sep 18, 2011 at 9:59 AM, Stefan Keller sfkel...@gmail.com wrote:
Merlin and Jeff,
General remark again:It's hard for me to imagine that btree is
superior for all the issues mentioned before. I still believe in
19.09.11 18:19, Robert Klemme написав(ла):
On Mon, Sep 19, 2011 at 4:04 PM, Merlin Moncuremmonc...@gmail.com wrote:
Postgres's hash index implementation used to be pretty horrible -- it
stored the pre-hashed datum in the index which, while making it easier
to do certain things, made it
Robert Klemme shortcut...@googlemail.com writes:
I still haven't seen a solution to locking when a hash table needs
resizing. All hashing algorithms I can think of at the moment would
require a lock on the whole beast during the resize which makes this
type of index impractical for certain
19.09.11 18:19, Robert Klemme написав(ла):
I still haven't seen a solution to locking when a hash table needs
resizing. All hashing algorithms I can think of at the moment would
require a lock on the whole beast during the resize which makes this
type of index impractical for certain loads
On Mon, Sep 19, 2011 at 12:54 PM, Vitalii Tymchyshyn tiv...@gmail.com wrote:
19.09.11 18:19, Robert Klemme написав(ла):
I still haven't seen a solution to locking when a hash table needs
resizing. All hashing algorithms I can think of at the moment would
require a lock on the whole beast
On Mon, Sep 19, 2011 at 8:19 AM, Robert Klemme
shortcut...@googlemail.com wrote:
On Mon, Sep 19, 2011 at 4:04 PM, Merlin Moncure mmonc...@gmail.com wrote:
The other way to go of course is to try and fix up the existing hash
index code -- add wal logging, etc. In theory, a customized hash
On Mon, Sep 19, 2011 at 10:19 AM, Robert Klemme
shortcut...@googlemail.com wrote:
On Mon, Sep 19, 2011 at 4:04 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Sun, Sep 18, 2011 at 9:59 AM, Stefan Keller sfkel...@gmail.com wrote:
Merlin and Jeff,
General remark again:It's hard for me to
On Mon, Sep 19, 2011 at 3:43 PM, Merlin Moncure mmonc...@gmail.com wrote:
To make the test into i/o bound, I change the setrandom from 10 to
1000; this produced some unexpected results. The hash index is
pulling about double the tps (~80 vs ~ 40) over the hybrid version.
Well, unless
Let's say that I want to do INSERT SELECT of 1,000 items into a table. The
table has some ints, varchars, TEXT and BLOB fields.
Would the time that it takes, differ a great deal, depending on whether the
table has only 100,000 or 5,000,000 records?
Thanks
i
On Mon, Sep 19, 2011 at 4:11 PM, Igor Chudov ichu...@gmail.com wrote:
Let's say that I want to do INSERT SELECT of 1,000 items into a table. The
table has some ints, varchars, TEXT and BLOB fields.
Would the time that it takes, differ a great deal, depending on whether the
table has only
Igor,
* Igor Chudov (ichu...@gmail.com) wrote:
Would the time that it takes, differ a great deal, depending on whether the
table has only 100,000 or 5,000,000 records?
Yes, because PostgreSQL is going to copy the data. If you don't need or
want it to be copied, just use a view. I've never
On Mon, Sep 19, 2011 at 6:32 PM, Scott Marlowe scott.marl...@gmail.comwrote:
On Mon, Sep 19, 2011 at 4:11 PM, Igor Chudov ichu...@gmail.com wrote:
Let's say that I want to do INSERT SELECT of 1,000 items into a table.
The
table has some ints, varchars, TEXT and BLOB fields.
Would the time
* Igor Chudov (ichu...@gmail.com) wrote:
Well, my question is, rather, whether the time to do a bulk INSERT of N
records into a large table, would take substantially longer than a bulk
insert of N records into a small table. In other words, does the populating
time grow as the table gets more
On Mon, Sep 19, 2011 at 7:53 PM, Stephen Frost sfr...@snowman.net wrote:
Igor,
* Igor Chudov (ichu...@gmail.com) wrote:
Would the time that it takes, differ a great deal, depending on whether the
table has only 100,000 or 5,000,000 records?
Yes, because PostgreSQL is going to copy the data.
* Jon Nelson (jnelson+pg...@jamponi.net) wrote:
Isn't the WAL basically COW?
eh..? No.. The WAL is used to record what changes are made to the
various files in the database, it certainly isn't an kind of
copy-on-write system, where we wait until a change is made to data
before copying it..
If
I have a lot of wasted bytes in some tables.
Somewhere I read that maybe auto-vacuum can't release space due to a low
max_fsm_pages setting.
I want to increase it, but I don't found the param in the postgres.conf.
This param exists? If not? How can I deal with bloated tables?
I have
On Mon, Sep 19, 2011 at 10:28 PM, Anibal David Acosta a...@devshock.com wrote:
I have a lot of wasted bytes in some tables.
Somewhere I read that maybe auto-vacuum can’t release space due to a low
max_fsm_pages setting.
It's no longer there, as fsm was moved from memory (which was limited
by
On 09/20/2011 09:21 AM, Jon Nelson wrote:
Isn't the WAL basically COW?
Nope, it's a lot more like a filesystem journal - though it includes all
data, not just metadata like filesystem journals usually do.
Now, you could argue that PostgreSQL uses a copy-on-write like system to
maintain row
26 matches
Mail list logo
