At one point I was working on a patch to pgbench to have it adopt 64-bit
math internally even when running on 32 bit platforms, which are
currently limited to a dataabase scale of ~4000 before the whole process
crashes and burns. But since the range was still plenty high on a
64-bit system, I
Samuel Gendler wrote:
I was trying to make the point that, in an attempt to make things very
easy for novice users, we are actually making them quite a bit more
complex for novice users who want to do anything besides start the server.
People who can't start the server often abandon PostgreSQL
On Fri, Jan 7, 2011 at 7:07 AM, Tom Lane wrote:
> Samuel Gendler writes:
> > Does it not seem that this insistence on shipping a default config that
> > works out of the box on every system incurs a dramatic penalty when it
> comes
> > to getting a useful postgres config for a production system?
Samuel Gendler writes:
> Does it not seem that this insistence on shipping a default config that
> works out of the box on every system incurs a dramatic penalty when it comes
> to getting a useful postgres config for a production system?
> I'm sure this argument has probably been done to death o
On Thu, Jan 6, 2011 at 8:37 PM, Greg Smith wrote:
> Josh Berkus wrote:
>
>> We talked about bumping it to 512kB or 1MB for 9.1. Did that get in?
>> Do I need to write that patch?
>>
>>
>
> If it defaulted to 3% of shared_buffers, min 64K & max 16MB for the auto
> setting, it would for the most p
Try
order by created_at+0
On 1/6/11, Mike Broers wrote:
> Thanks for the assistance.
>
> Here is an explain analyze of the query with the problem limit:
>
> production=# explain analyze select * from landing_page.messages where
> ((messages.topic = E'x') AND (messages.processed = 'f')) ORDER BY
On Friday, January 07, 2011 02:45:02 PM Florian Weimer wrote:
> * Andres Freund:
> > On Friday, January 07, 2011 01:45:25 PM Florian Weimer wrote:
> >> On 9.0, this configuration
> >>
> >> checkpoint_segments = 512 # in logfile segments, min 1, 16MB each
> >>
> >> results in 1034 segments, so
* Andres Freund:
> On Friday, January 07, 2011 01:45:25 PM Florian Weimer wrote:
>> On 9.0, this configuration
>>
>> checkpoint_segments = 512 # in logfile segments, min 1, 16MB each
>>
>> results in 1034 segments, so the effective logfile segment size is 32 MB.
> Um. Is it possible that you
On Friday, January 07, 2011 01:45:25 PM Florian Weimer wrote:
> On 9.0, this configuration
>
> checkpoint_segments = 512 # in logfile segments, min 1, 16MB each
>
> results in 1034 segments, so the effective logfile segment size is 32 MB.
Um. Is it possible that you redefined XLOG_SEG_SIZE or
On 9.0, this configuration
checkpoint_segments = 512 # in logfile segments, min 1, 16MB each
results in 1034 segments, so the effective logfile segment size is 32 MB.
The documentation says this:
Maximum number of log file segments between automatic WAL
checkpoints (each segment is
Fair enough!
I also turned seqscan off, so the new plan (for the NOT EXISTS) is:
Merge Anti Join (cost=0.00..212686.89 rows=1 width=313) (actual
time=0.426..14921.344 rows=63836 loops=1)
Merge Cond: ((d2.hwdocid)::text = (d.hwdocid)::text)
-> Index Scan using hwdocid2_uniq on "Doc2" d2 (cost=0.
Hi All:
The autovacuum (prevent wraparound) still run more than 36 hours, I can not
drop the partition table after adjust the autovacuum parameters.
If a table is running autovacuum (prevent wraparound), can I purge this
table?
If not, what else I can do for clean this partition table?
If the t
Hi,
I had a similar problem with many left join, reading about planning
optimization i tried to edit postgresql.conf and uncommented the line
join_collapse_limit = 8 and set it to 1, disables collapsing of explicit .
My query its taking 2000s in 8.4 and the same query 2ms in 8.3. Now its
working
On Dec 28 2010, 9:55 pm, kakarukeys wrote:
> On Dec 28, 9:37 pm, singh.gurj...@gmail.com (Gurjeet Singh) wrote:
>
>
>
> > On Tue, Dec 28, 2010 at 2:08 AM, kakarukeys wrote:
> > > I have a table "aaa" which is not very big. It has less than 10'000
> > > rows. However read operations on this table
Hi All:
The autovacuum (prevent wraparound) still run more than 36 hours, I can not
drop the partition table after adjust the autovacuum parameters.
If a table is running autovacuum (prevent wraparound), can I purge this
table?
If not, what else I can do for clean this partition table?
If the t
15 matches
Mail list logo